Created attachment 19046 [details] test case I noticed problems with materials in my game - for some reason the whole scene is rendered with one color. After some experiments I found that this is first color passed to the glMaterialfv. I thought it's problem with my game, so I wrote simple program which renders two quads - and problem still exists there. I tried with hardware acceleration (r300) and without it (LIBGL_ALWAYS_INDIRECT) - in both cases everything was rendered in one color. So I tried fglrx - and it worked correctly - there are different colors after each glMaterial call. So I believe there is a bug in Mesa. Problem doesn't exist when using GL_COLOR_MATERIAL (which is probably the reason nobody found it before). Problem doesn't exist when using display lists. Problem doesn't exist when using gluBeginSurface/gluEndSurface (probably it clears some state). Please compile attached test case with: g++ material.cc -lSDL -lGL On Mesa you will notice two rectangles with same color, on fglrx you will notice two rectangles with different colors.
See also bug 13258. I wonder if this is r300 driver specific or if other drivers running the tnl vertex program on the GPU (i965?) are also affected.
I have just tried this with LIBGL_ALWAYS_SOFTWARE=1 and I get two rectangles: one green and one red. LIBGL_ALWAYS_INDIRECT=1 forces AIGLX, of course, so I get the same behavior as with direct rendering.
LIBGL_ALWAYS_SOFTWARE=1 didn't help here, I use Mesa 7.0.3 and xf86-video-ati 6.8.0 from Arch Linux packages
LIBGL_ALWAYS_SOFTWARE tells libGL to use swrast_dri.so instead of the hardware-specific DRI object, so you would need to have this object in your dri/ directory.
(In reply to comment #3) > LIBGL_ALWAYS_SOFTWARE=1 didn't help here, I use Mesa 7.0.3 [...] 7.0.x doesn't have the swrast driver yet and ignores LIBGL_ALWAYS_SOFTWARE .
This has just been fixed in Mesa 7.3-devel (git).
(In reply to comment #6) > This has just been fixed in Mesa 7.3-devel (git). My mistake - no it hasn't. This is actually what's going on: $ LIBGL_DEBUG=1 /usr/libexec/xscreensaver/rubik libGL error: dlopen /usr/local/lib/dri/r300_dri.so failed (/usr/local/lib/dri/r300_dri.so: undefined symbol: _tnl_ProgramCacheDestroy) libGL error: unable to load driver: r300_dri.so Mesa then resorts to software rendering instead.
So with software rendering it works correctly for you? In that case should I report this bug to r300? I am sure that LIBGL_ALWAYS_INDIRECT on my system leads to "slow" rendering and this bug still appears, is it some kind of indirect hardware acceleration rendering? I use glxgears to check if hardware acceleration (fast) rendering is enabled. When it's disable gears react slowly on keyboard, on fast they react immediately.
(In reply to comment #8) > So with software rendering it works correctly for you? In that case should I > report this bug to r300? It does sound like an r300 bug to me, yes. > I am sure that LIBGL_ALWAYS_INDIRECT on my system leads to "slow" rendering and > this bug still appears, is it some kind of indirect hardware acceleration > rendering? That would be AIGLX. Check whether you have AIGLX enabled in your xorg.conf file, and maybe try running your test program again with it disabled.
Could you try removing ctx->VertexProgram._MaintainTnlProgram = GL_TRUE; line from r300_context.c It fixes color material for me on rs690 (non tcl hw).
(In reply to comment #10) > Could you try removing > ctx->VertexProgram._MaintainTnlProgram = GL_TRUE; > line from r300_context.c > > It fixes color material for me on rs690 (non tcl hw). That's not a solution for hardware which needs the fixed-function vertex program though. The i965 driver also seems affected by this, reassigning to Mesa core.
(In reply to comment #10) > Could you try removing > ctx->VertexProgram._MaintainTnlProgram = GL_TRUE; > line from r300_context.c > > It fixes color material for me on rs690 (non tcl hw). Hmm, either git-mesa hasn't built correctly, or this doesn't work on a Radeon 9550: (gdb) run Starting program: /usr/libexec/xscreensaver/rubik (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0xb7f0a700 (LWP 7677)] Program received signal SIGSEGV, Segmentation fault. 0xb7dcd904 in _mesa_load_state_parameters (ctx=0x8079180, paramList=0x80ac3f8) at shader/prog_statevars.c:1017 1017 if (paramList->Parameters[i].Type == PROGRAM_STATE_VAR) {
(In reply to comment #12) > (In reply to comment #10) > > Could you try removing > > ctx->VertexProgram._MaintainTnlProgram = GL_TRUE; > > line from r300_context.c > > > > It fixes color material for me on rs690 (non tcl hw). > > Hmm, either git-mesa hasn't built correctly, or this doesn't work on a Radeon > 9550: > > (gdb) run > Starting program: /usr/libexec/xscreensaver/rubik > (no debugging symbols found) > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > [New Thread 0xb7f0a700 (LWP 7677)] > > Program received signal SIGSEGV, Segmentation fault. > 0xb7dcd904 in _mesa_load_state_parameters (ctx=0x8079180, paramList=0x80ac3f8) > at shader/prog_statevars.c:1017 > 1017 if (paramList->Parameters[i].Type == PROGRAM_STATE_VAR) { > Looks like TCL path needs some more investigation, unfortunately currently I don't have TCL enabled cards to do it.
Works for me with swrast, softpipe, r300g, and r300c. Closing...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.