GLX indirect rendering broken

[Ian Romanick]

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

Brian Paul wrote:
> 
> After fixing a few issues in Mesa related to renderbuffers (patch to
> follow) I still found that indirect rendering was broken, though I found
> that only certain programs generated the BadLength protocol error.
> 
> With some debugging I found that anytime one of the functions in
> indirect_size.c was called, I'd get the protocol error, otherwise,
> things were OK.
> 
> All the functions in indirect_size.c look like this:
> 
> INTERNAL PURE FASTCALL GLint
> __glCallLists_size( GLenum e )
> {
>    ...
> }
> 
> 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

That's interesting.  My guess would be that the code is built with
FASTCALL, but the callers are not.  It would be easy enough to find out
by looking at a disassembly of the caller.  This is particularly odd
because it did work at one time.

> 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.

It tends to improve performance a trivial amount, but it also tends to
reduce code size a bit.  Since there are a ton of various internal
functions, I sprinkled FASTCALL around quite liberally.  The other thing
to remember is that the same code is used on the server and the client.
 That means we get the (trivial) performance and code size benefit twice.

I'll look into this some today.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDOCu/X1gOwKyEAw8RAqzzAJ0XADwpPZrawXYIarFa5bQ3wqHZvgCgg7up
UtlRCprMBxP5MtpWkb0pxTk=
=RxyN
-----END PGP SIGNATURE-----