On 03/10/2013 11:24 AM, Stefan Brüns wrote:
Hi everyone,
I have run into a problem leading to a crashing X server for a bunch of
indirect GLX calls.
This problem affects any OpenGL clients using indirect rendering and calling
functions which are outside the ABI. Problems range from malfunctioning to
crashes.
Problem analysis:
The dispatcher functions in glx/indirect_dispatch.c demarshall the function
arguments from the GLX wire protocol and then call the appropriate function of
the GL library. Function calls are done using dispatch table with the help of
the CALL_* helper macros defined in dispatch.h.
Unfortunately there is a mismatch between the dispatch table expected by the
xserver - which follows the layout e.g. found in glapitable.h - and the one
provided by the GL library, e.g. Mesa.
The dependency is the other way around. The loader (either libGL on the
client or the GLX extension in the server) dictates the layout of the
dispatch table. The GL driver is required to adapt to the layout
dictated by the loader. That's the whole reason the remap table exists.
The driver queries the loader to learn where functions are located in
the dispatch table. It then stores the dispatch table locations at
(fixed) locations in the remap table. So, the driver knows that glFoo
is at location 824 in the remap table, and that entry stores the
location of glFoo in the dispatch table.
It sounds like something else is going wrong.
Although both tables are created from the definitions in the various xml files
part of Mesa, the xserver table omits the slots for the EGL methods and
various others.
Possible solutions:
1. Use the approach used by XQuartz, i.e. allocate a table und fill the slots
using dlsym.
Pros: works independend on X/Mesa version, no additional runtime cost
Cons: increased startup time
Note that there's nothing to dlsym. The server loads the driver
directly. It doesn't (and can't!) use libGL.
2. Make sure the Xserver uses the same table layout, i.e. insert some empty
slots in the right positions.
Pros: no additional runtime or setup cost
Cons: new slots must only be appended to the table
3. Use the remap table
Pros: adapts to changes in the GL library
Cons: needs the (mesa internal) remap table, i.e. only applicable to Mesa,
runtime cost due to the extra level of indirection.
Which would be the preferred approach, are there any other?
A bug has been filed against the Xserver:
https://bugs.freedesktop.org/show_bug.cgi?id=61022
Regards,
Stefan
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev