Hi, Michael, Thanks for the questions and information... Responses follow:
This only happens with glBitmap(). I don't see it with either glDrawPixels (GL_RGB or GL_RGBA format, with GL_UNSIGNED_BYTE data) or GL_QUADS (or equivalent glRect). I saw banding when I tried 6.5.2-4 Mesa with direct or indirect rendering, with indirect rendering done via: $ LIBGL_ALWAYS_INDIRECT=1 ./faded freeglut (./faded): Unable to create direct context rendering for window 'Blend test' This may hurt performance. But as you point out, DRI is loaded on X server startup in all those tests: $ grep AIGLX /var/log/Xorg.0.log (==) AIGLX enabled (WW) AIGLX: 3D driver claims to not support visual 0x23 ...snip... (WW) AIGLX: 3D driver claims to not support visual 0x32 (II) AIGLX: Loaded and initialized /usr/lib/dri/r200_dri.so If I disable DRI and restart the X server, then rerun the test program with or without forced indirect rendering like so: $ grep AIGLX /var/log/Xorg.0.log (==) AIGLX enabled (EE) AIGLX: DRI module not loaded $ ./faded freeglut (./faded): Unable to create direct context rendering for window 'Blend test' This may hurt performance. $ LIBGL_ALWAYS_INDIRECT=1 ./faded freeglut (./faded): Unable to create direct context rendering for window 'Blend test' This may hurt performance. Then I see a very nice 50% gray screen and no banding in all the tests against 6.5.2-4. I should say that the personal incentive for filing this bug was the change in DRI blending behavior from 6.5.1-0.6 to 6.5.2-4, this is all in hopes of isolating what happened... Please let me know if there is anything else I could do to help isolate this? I don't mind mucking around in code if it is of any use. Thanks, Dan On 5/14/07, Michel Dänzer <[EMAIL PROTECTED]> wrote: ...
Does this also happen when rendering say a GL_QUAD instead of using glBitmap?
...
As indirect rendering seems to fail consistently (the xlib backend works completely differently), did you double-check that these cases were really using direct rendering?
...
Note that when AIGLX is enabled (check Xorg.0.log), the Mesa *_dri.so driver will be used in both cases, though in contrast to direct rendering the X server will only load it once on X startup. > I'm reporting this against libgl1-mesa-dri, though perhaps it could > as easily be against libgl1-mesa-glx or the mesa source package? Or xserver-xorg-core...
...
Can't reproduce it with the r300 driver from more or less up to date Mesa GIT here even with indirect rendering.
