| Summary: | setting material is broken | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Jacek Poplawski <jacekpoplawski> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 7.0.3 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | test case | ||
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.
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.