mesa3d-dev

[Mesa3d-dev] code generation for dynamic extensions broken ?

[George S. <gsa...@gm...>]

Hi,

I made a small test to test code genration for dynamic extensions in
http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test

When using libGL + swrast_dri.so from getproc-test, the dynamic
extensions code is not exercised and the test passes.

When using libGL from mesa 7.7 and swrast_dri.so from getproc-test,
the extension string does contain GL_MESA_test_extension but the test
segfaults.

It seems that dynamic extensions code is broken (since at least 7.7),
unless there is something wrong with the test or my arch:

model name	: AMD Athlon(tm) XP 2200+
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up

regards,
George.

Re: [Mesa3d-dev] code generation for dynamic extensions broken ?

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

George Sapountzis wrote:

> I made a small test to test code genration for dynamic extensions in
> http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test
> 
> When using libGL + swrast_dri.so from getproc-test, the dynamic
> extensions code is not exercised and the test passes.
> 
> When using libGL from mesa 7.7 and swrast_dri.so from getproc-test,
> the extension string does contain GL_MESA_test_extension but the test
> segfaults.

There are a few places where this could break.

 - The generated dispatch stub function is wrong.
 - The dispatch offset used by the driver is wrong.
 - The dispatch remapping used by the driver is wrong.

The easiest way to check this is probably to set a breakpoint in
_mesa_init_exec_table at the line after the SET_TestExtensionMESA.  Look
at driDispatchRemapTable[TestExtensionMESA_remap_index].  Does it seem
sensible?  Look at the function stored in the dispatch table at that
offset.  Does it look sensible?

> It seems that dynamic extensions code is broken (since at least 7.7),
> unless there is something wrong with the test or my arch:
> 
> model name	: AMD Athlon(tm) XP 2200+
> flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
> pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuVYBYACgkQX1gOwKyEAw9eMwCfWcgdWnjN37FYDn6Q6nv1GXLG
Zj8AoIlciQ5+yp9RxFnKmYCdCcbYUklr
=OTOr
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] code generation for dynamic extensions broken ?

[George S. <gsa...@gm...>]

On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick <id...@fr...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> George Sapountzis wrote:
>
>> I made a small test to test code genration for dynamic extensions in
>> http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test
>>
>> When using libGL + swrast_dri.so from getproc-test, the dynamic
>> extensions code is not exercised and the test passes.
>>
>> When using libGL from mesa 7.7 and swrast_dri.so from getproc-test,
>> the extension string does contain GL_MESA_test_extension but the test
>> segfaults.
>
> There are a few places where this could break.
>
>  - The generated dispatch stub function is wrong.
>  - The dispatch offset used by the driver is wrong.
>  - The dispatch remapping used by the driver is wrong.
>

It turned out that there were two bugs in glapi. One with using
non-exec memory and the other with using an un-relocated function
template for entry-point generation. I put fixes at:

http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-debug

I also tested with libGL pretending to not know fbo extensions, the
fbo* demos and tests render correctly. I get a warning about an
invalid enum in RenderbufferStorageMultisample(target) but i don't
know where it comes from and it does not affect rendering.

Since we are already generating static dispatch stubs for all known
extensions, I guess we can add a few more static stubs and use them,
instead of generating on-the-fly. I put an example about this in the
getproc-debug branch, but I don't know if it's a good idea.

regards,
George.

Re: [Mesa3d-dev] code generation for dynamic extensions broken ?

[George S. <gsa...@gm...>]

On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis
<gsa...@gm...> wrote:
>
> I also tested with libGL pretending to not know fbo extensions, the
> fbo* demos and tests render correctly. I get a warning about an
> invalid enum in RenderbufferStorageMultisample(target) but i don't
> know where it comes from and it does not affect rendering.

ignore the warning, it's due to a forgotten debugging call to the
first dynamic function assuming it's the test extension, which is not
the case with fbo.

Re: [Mesa3d-dev] code generation for dynamic extensions broken ?

[tom f. <tf...@al...>]

George Sapountzis <gsa...@gm...> writes:
> On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick <id...@fr...> wrote:
> > George Sapountzis wrote:
> >
> >> When using libGL from mesa 7.7 and swrast_dri.so from getproc-test,
> >> the extension string does contain GL_MESA_test_extension but the test
> >> segfaults.
> >
> > There are a few places where this could break.
> >
> >  - The generated dispatch stub function is wrong.
> >  - The dispatch offset used by the driver is wrong.
> >  - The dispatch remapping used by the driver is wrong.
> 
> It turned out that there were two bugs in glapi. One with using
> non-exec memory and the other with using an un-relocated function
> template for entry-point generation. I put fixes at:
> 
> http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-debug

Some comments:

  e38a234.. shouldn't get merged as-is, right?  I mean, there must be
  some sort of mesa_debug macro or similar, so that debug messages are
  configurable.

  ditto for d0b35e9.

  d6c973c is a strange patch; the additions to GLAPI_SOURCES seem
  unrelated to the patch itself.

  977d5d: it seems like there should be some other way to disable this.
  I've been trying to make time to have these XMLs be exhaustive in
  their coverage of GL and GLX extensions, for example, which is good
  for other reasons.

  Most importantly: have you tested with mangled symbols (compile w/
  USE_MGL_NAMESPACE defined)?  It looks like the functions added in
  682971c need #ifdef MANGLE cases.

A few months back, I noticed some cases of doing function lookup
without considering mangled symbols, but couldn't reproduce it in
my setup.  I think it had to do with loading the symbols from a DRI
driver.  It might have even been fine, i.e. a higher level scrubbed out
the mangling.  I guess I'm saying that if you tested mangling && it
still works, great, `done' in my book :)

Cheers,

-tom

Re: [Mesa3d-dev] code generation for dynamic extensions broken ?

[George S. <gsa...@gm...>]

>
> Some comments:
>
>  e38a234.. shouldn't get merged as-is, right?  I mean, there must be
>  some sort of mesa_debug macro or similar, so that debug messages are
>  configurable.
>
>  ditto for d0b35e9.
>

right. from getproc-cleaunp..getproc-debug only the two fixes will be merged

>  d6c973c is a strange patch; the additions to GLAPI_SOURCES seem
>  unrelated to the patch itself.

mesa_exec_malloc is defined in the added sources from main/

>
>  977d5d: it seems like there should be some other way to disable this.
>  I've been trying to make time to have these XMLs be exhaustive in
>  their coverage of GL and GLX extensions, for example, which is good
>  for other reasons.

that was in order to test adding fbo extensions on-the-fly, not
intended for merging.

>
>  Most importantly: have you tested with mangled symbols (compile w/
>  USE_MGL_NAMESPACE defined)?  It looks like the functions added in
>  682971c need #ifdef MANGLE cases.
>
the commit just moves code. I guess get_extension_proc() needs ifdef's
for mangle similar to get_static_proc(), but that can be fixed
separately

thanks,
George.