[Mesa3d-dev] Re: GLX indirect rendering broken

Brian Paul brian.paul at tungstengraphics.com
Mon Sep 26 18:08:51 PDT 2005

Ian Romanick wrote:
> Hash: SHA1
> Ian Romanick wrote:
>>Ian Romanick wrote:
>>>>Brian Paul wrote:
>>>>>>Well, disabling the FASTCALL macro fixed all my problems.
>>>>>>Ian, it looks like you wrote that code.  I don't know why the FASTCALL
>>>>>>business is causing trouble, but I'm very tempted to simply
>>>>>>disable/remove it.  Is there any good reason for it?  I can't imagine it
>>>>>>making any real difference in performance.  No GL program is going to be
>>>>>>limited by the speed of those particular functions.
>>>>I think I found the problem, but I haven't had a change to build and
>>>>test it yet.  It looks like some of the __gl*_size prototypes existed in
>>>>two files.  One set is in indirect_size.h (the correct file that is
>>>>generated form glAPI.xml) and one set is in impsize.h (the incorrect
>>>>file).  The attached patch should fix that.
>>>>Whether the FASTCALL stuff stays or goes, I don't think we want multiple
>>>>copies of the prototypes floating around.  As soon as 7.0 sets sail,
>>>>I'll have a bunch more patches that replace a *LOT* of the code in
>>>>programs/Xserver/GL/glx with generated files.  When that happens,
>>>>impsize.h will go away altogether.
>>Try this patch instead.  This one will actually compile. ;)  I have
>>run-tested it yet, but the disassembly of rensize.o appears to use the
>>right calling convention for the __gl*_size functions.
> Using that patch and the Mesa-6.4 branch I have been unable to reproduce
> any segfaults or protocol errors.  I have committed the patch.

Great.  I'll try to re-test in a day or two to double-check.

I think I'm going to wrap up Mesa 6.4 pretty soon.  The branch has a 
significant number of bug fixes that should go into the X server release.


More information about the xorg mailing list