Bug 185286

Summary: glxinfo erroneously reports "direct rendering: No"
Product: [Fedora] Fedora Reporter: Joachim Frieben <jfrieben>
Component: mesaAssignee: Adam Jackson <ajax>
Status: CLOSED RAWHIDE QA Contact: X/OpenGL Maintenance List <xgl-maint>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-24 10:37:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg.0.log for SuperSavage IX/C w/DRI enabled
none
glxinfo output for SuperSavage IX/C w/DRI enabled
none
ldd output of /usr/bin/glxinfo for SuperSavage IX/C w/DRI enabled none

Description Joachim Frieben 2006-03-13 09:26:46 UTC
Description of problem:
On my SuperSavage IX/C powered IBM ThinkPad T23, direct rendering is
enabled for the X server which is confirmed in X.0.log. Proper 3D
acceleration is verified by comparison of GL screensavers with and
with enabled or disabled DRI. However, even in the accelerated case,
glxinfo claims:

  "direct rendering: No"

This statement is wrong.

Version-Release number of selected component (if applicable):
mesa-libGL-6.4.2-6

How reproducible:
Always

Steps to Reproduce:
1. Start X.
2. Lock screen after choosing "flurry" screensaver module.
3. Unlock screen and execute glxinfo.
  
Actual results:
glxinfo reports: "direct rendering: No"

Expected results:
glxinfo reports: "direct rendering: Yes"

Additional info:
Executing glxinfo after setting LIBGL_DEBUG to verbose does
not produce any additional output.
glxinfo does produce the correct result on a fresh FC5T3 though.
Downgrading kernel, mesa libs and libc from current rawhide to
their FC5T3 counterparts does not change anything either. glxinfo
still gives the wrong result.

Comment 1 Joachim Frieben 2006-03-13 09:26:46 UTC
Created attachment 126026 [details]
Xorg.0.log for SuperSavage IX/C w/DRI enabled

Comment 2 Joachim Frieben 2006-03-13 09:27:54 UTC
Created attachment 126027 [details]
glxinfo output for SuperSavage IX/C w/DRI enabled

Comment 3 Adam Jackson 2006-03-13 15:24:16 UTC
Please attach the output of:

LIBGL_DEBUG=verbose glxinfo

if it's different than the output attached above.  If there's no additional
output when LIBGL_DEBUG=verbose, please attach the output of

ldd `which glxinfo`

Comment 4 Joachim Frieben 2006-03-13 15:55:14 UTC
As stated above, the output of glxinfo is identical in both cases. This
is already surprising as there used to be some (useless) complaint about
missing "drirc" files which is now absent. Maybe M. Harris rendered the
GL libs more quiet in the latest builds ... possibly a bit too quiet.

   'which glxinfo' returns: /usr/bin/glxinfo

The "ldd" output is attached.

Comment 5 Joachim Frieben 2006-03-13 15:57:01 UTC
Created attachment 126046 [details]
ldd output of /usr/bin/glxinfo for SuperSavage IX/C w/DRI enabled

Comment 6 Joachim Frieben 2006-03-16 10:57:52 UTC
I have obtained the following benchmark results for "glxgears" for
a default windows size of 300x300 pixels:

  24 bpp:  90 fps w/ DRI,  145 fps w/o DRI
  16 bpp: 215 fps w/ DRI,  215 fps w/o DRI

Right now, "glxgears" reports frame rates with enabled "DRI" that
are at best on par with "DRI" disabled and even significantly
inferior at 24 bpp. This looks sort of pathological.

Comment 7 Mike A. Harris 2006-03-16 11:13:58 UTC
(In reply to comment #4)
> As stated above, the output of glxinfo is identical in both cases. This
> is already surprising as there used to be some (useless) complaint about
> missing "drirc" files which is now absent. Maybe M. Harris rendered the
> GL libs more quiet in the latest builds ... possibly a bit too quiet.

I haven't rendered anything "more quiet".  The src.rpm is publically
downloadable, so there's no need to guess.
 
The most common reason for DRI not working as expected in this manner,
is having multiple libGL's installed, and getting the wrong one. This
often happens if you manually build Mesa or use downloadable prebuilt
tarball binaries, etc.

If the X server log indicates DRI is enabled, and glxinfo indicates DRI
is not being used, and you are executing the glxinfo binary at a shell which
is on the same local machine as the X server which is managing the display
you are viewing, that usually indicates a libGL mismatch as mentioned
above.

At this point, I'd strongly recommend discussing the problem on the DRI
mailing lists.  

On a side note, the (2D) savage driver you're using seems to be rather chatty,
and seems to be spewing a lot of debug info.  If that's our driver, it's
the stock X.Org driver, and should probably also be reported to upstream
X.Org bugzilla at http://bugs.freedesktop.org

HTH

Comment 8 Joachim Frieben 2006-03-16 12:51:05 UTC
This is a clean install from the Fedora development tree carried
out on **2006-03-14** with a couple of available updates over the last
2 days. No, no external add-ons (I haven't heard about propietary
"savage driver packages yet). The "savage" driver package is the original
Fedora one (xorg-x11-drv-savage-2.0.2.3-1.2) and it is *identical* to
that of FC5T3 for which "glxinfo" behaved absolutely *normally*. I even
reinstalled FC5T3 after my initial report to explicitly verify this
issue. The system is an IBM ThinkPad T23 connected to an external LG 1710B
monitor, and I am sitting in front of it, *no* remote session to a dumb
"X" terminal (sigh!).
The "Mesa" packages differ however: "mesa-libGL-6.4.2-2.1" vs
"mesa-libGL-6.4.2-6". The kernel is different, too. I further verified for
a current Ubuntu live CD. Here the issue is absent (modular "Xorg", etc.)

Btw, there is still a pending report for bug #180150 caused by M. Harris'
RV100 bus master patch which broke "DRI" for my Radeon R100 QD PCI
It's too easy a solution to direct people upstream when it's not even clear
whether the issue hasn't been introduced at the vendor level.
I understand that M. Harris may be tired of dealing with false bug reports.
There have been some comments on "fedora-devel" which indicate this.
However, this attitude is not acceptable from the point of view of the
individual tester who spends a significant amount of time and energy to
help make Fedora as bug-free as possible.

Comment 9 Joachim Frieben 2006-03-16 13:18:10 UTC
It's not an "SElinux" issue either (see my report for bug #176221),
as I booted with "enforcing=0" to rule out this type of problem
in the first place.

Comment 10 Joachim Frieben 2006-03-24 10:37:06 UTC
Fixed in rawhide.