>
> 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
George Sapountzis writes:
> On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick 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
On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis
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
On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick 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 + swra
-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
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
