Bug 10523

Summary: glActiveStencilFaceEXT causes noop dispatch on R300
Product: Mesa Reporter: Oliver McFadden <z3ro.geek>
Component: Drivers/DRI/r300Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: medium    
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: gdb
gdb

Description Oliver McFadden 2007-04-04 10:03:31 UTC
The glActiveStencilFaceEXT function causes a noop dispatch on R300. You can see
this with the progs/tests/getprocaddress test.

This is probably related to commit 62efc4ba3eb53ca75abbe9b52feabe49a5fd56b5
which adds support for (most of) the GL_EXT_stencil_two_side extension. I don't
think there is anything wrong with this commit, just the dispatching of the
glActiveStencilFaceEXT function.
Comment 1 Brian Paul 2007-04-04 12:03:27 UTC
Is line 340 of r300_context.c being executed: ?

		driInitSingleExtension(ctx, stencil_two_side);

Later the actual function should get plugged into the dispatch table in main/state.c at line 579:

   SET_ActiveStencilFaceEXT(exec, _mesa_ActiveStencilFaceEXT);

Note that GL_EXT_stencil_two_side is incompatible with OpenGL 2.0 - see comments at top of main/stencil.c
Comment 2 Oliver McFadden 2007-04-04 12:55:16 UTC
Even if I comment that line to make absolutely certain the call to driInitSingleExtension is executed, the getprocaddress test still fails.  I'm aware that GL_EXT_stencil_two_side conflicts with OpenGL 2.0, but this isn't a problem. I target OpenGL 1.3 plus extensions. 
Comment 3 Oliver McFadden 2007-04-04 13:10:01 UTC
Just to clarify, I of course mean commenting the if-statement line, not the driInitSingleExtension line itself. 
Comment 4 Oliver McFadden 2007-04-09 19:13:40 UTC
Has anyone got any ideas about this? I think that R300 is the only DRI driver to support this extension, so maybe something is broken in the code related to this extension? 
Comment 5 Brian Paul 2007-04-10 07:34:33 UTC
I don't have an R300.  I think someone with an R300 card who knows how to use gdb will just have to dig into the problem and figure it out.
Comment 6 Oliver McFadden 2007-04-10 14:44:01 UTC
Okay. I'll try to take a look into this further with gdb within the next few days. 
Comment 7 Oliver McFadden 2007-04-15 00:53:12 UTC
I just did some more debugging on this, and found that the extension is indeed initialized.  Breakpoint 1, _mesa_enable_extension (ctx=0x51fff0, name=0x2b817e8f0fbf "GL_EXT_stencil_two_side") at main/extensions.c:459 459        set_extension(ctx, name, GL_TRUE); (gdb)  Continuing. Mesa 6.5.3 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org  Program exited with code 01.  But it seems that I'm still getting the no-op dispatch. I checked and even ctx->Extensions->EXT_stencil_two_side it set correctly; it's set to 1.  I'm not sure why it's getting the no-op dispatch. Brian, could you offer some pointers about where to look to debug this further? 
Comment 8 Oliver McFadden 2007-04-15 00:55:18 UTC
Bugzilla messed up the formatting, so here's the message without the GDB log,
and I'll attach the GDB log separately.

I just did some more debugging on this, and found that the extension is indeed
initialized.

But it seems that I'm still getting the no-op dispatch. I checked and even
ctx->Extensions->EXT_stencil_two_side it set correctly; it's set to 1.

I'm not sure why it's getting the no-op dispatch. Brian, could you offer some
pointers about where to look to debug this further?
Comment 9 Oliver McFadden 2007-04-15 00:56:05 UTC
Created attachment 9609 [details]
gdb
Comment 10 Brian Paul 2007-04-16 07:59:29 UTC
What exactly is the error/warning that's printed?  Can you set a breakpoint in the warning function and get a stack trace?
Comment 11 Oliver McFadden 2007-04-16 08:55:20 UTC
Created attachment 9618 [details]
gdb

Here is a backtrace from getprocaddress. I don't remember which CFLAGS I
compiled Mesa with last, but in this case it makes little difference to the
backtrace.
Comment 12 Brian Paul 2007-04-16 16:19:24 UTC
OK, I think I've fixed this.  The problem was a misunderstanding of how the driInitExtensions() and driInitSingleExtension() functions are used.

Get the latest from git and close this report if it's OK.
Comment 13 Oliver McFadden 2007-04-16 23:32:53 UTC
Latest Git works perfectly, thanks! 
Comment 14 Adam Jackson 2009-08-24 12:26:21 UTC
Mass version move, cvs -> git

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.