[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:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
-Brian
More information about the xorg
mailing list