6.14.0 and 101_select_between_classic_and_gallium_dri.patch doesn't work properly

Bug #715939 reported by Alexandre Demers
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xserver-xorg-video-ati (Ubuntu)
Fix Released
High
Chris Halse Rogers

Bug Description

Binary package hint: xserver-xorg-video-ati

As it is, when applied, the patch as a negative impact on both visual rendering and performance. Not applying it fixes the problems observed.

It was tracked down on freedesktop.
See details and screenshots reported at https://bugs.freedesktop.org/show_bug.cgi?id=33918.

Revision history for this message
Alexandre Demers (oxalin) wrote :

Obviously, from the title, I'm talking about the 101_select_between_classic_and_gallium_dri.patch.

Revision history for this message
Chris Halse Rogers (raof) wrote :

Are you referring to rendering with the default Ubuntu mesa, or that the ForceGallium option interferes with testing local builds of mesa?

Changed in xserver-xorg-video-ati (Ubuntu):
status: New → Incomplete
importance: Undecided → High
assignee: nobody → Chris Halse Rogers (raof)
Revision history for this message
Alexandre Demers (oxalin) wrote :

I should have mentionned the tests were done using latest Mesa from git, libdrm 2.4.23 (needed by both latest xserver-xorg-video-ati and Mesa) and that I can boot under kernels 2.6.35.11, 2.6.36.3, 2.6.37 and 2.6.38-rc4. Kernel 2.6.37 was used for testing. As you can see in the screenshots, when building my package with the 101_select_between_classic_and_gallium_dri.patch, some shadows were not rendered correctly (what can't be seen is the fact the tests were choppy). Without that patch, everything is fine in terms of rendering (shadows) and performances.

Option "ForceGallium" "True" has been added in xorg.conf.

Revision history for this message
Chris Halse Rogers (raof) wrote :

I suspect that what's actually happening here is that, when ForceGallium is enabled, mesa isn't loading the dri module - because ForceGallium causes mesa to look for r600g_dri.so rather than r600_dri.so.

Does copying r600_dri.so to r600g_dri.so in your mesa build fix things? That's what we do in the Ubuntu mesa build - copy the gallium driver to r600g_dri.so so we can install both r600c and r600g.

Revision history for this message
Alexandre Demers (oxalin) wrote :

That makes sense because when compiling mesa from git, the file is not renamed to r600g_dri.so. I'll try it to be sure.

A simple question though : why is the naming convention different between r300 (r300_dri.so is the gallium driver, r300c_dri.so is classic) and r600 (r600_dri.so is the classic driver, r600g_dri.so is gallium)?

Revision history for this message
Robert Hooker (sarvatt) wrote :

because gallium is the default for r300 but the less mature r600 gallium driver is not yet. the classic r300 is there in case someone boots without KMS for example so it will fall back automatically, something that doesn't happen without 101_select_between_classic_and_gallium_dri.patch.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-ati - 1:6.14.0-0ubuntu1

---------------
xserver-xorg-video-ati (1:6.14.0-0ubuntu1) natty; urgency=low

  * New upstream release
  * Drop 101_select_between_classic_and_gallium_dri.patch. Default to gallium
    everywhere, and rely on libGL and the Xserver to fallback when necessary
    (LP: #715939)
 -- Christopher James Halse Rogers <email address hidden> Fri, 18 Feb 2011 13:32:01 +1100

Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.