GLX indirect rendering broken
idr at us.ibm.com
Mon Sep 26 10:11:27 PDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
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)
-----END PGP SIGNATURE-----
More information about the xorg