On 03/20/2013 02:43 PM, Stefan Brüns wrote:
On Tuesday 12 March 2013 09:25:07 Ian Romanick wrote:
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.

Currently this obviously can not work.

The remap table is only used when FEATURE_remap_table is defined, which for
the X server is never true.

Now, lets try defining FEATURE_remap_table for the xserver (which breaks OS X
and windows builds of Mesa, but anyway ...)

Xserver has nothing to do with it. The remap table is entirely in the driver (*_dri.so). The xserver has no knowledge about the remap table whatsoever. The xserver only knows about the dispatch table, and it dictates where things are in that table.

It's been a long time since I wrote this code, but I haven't been able to kill of all the memories of it yet. :)

Even then, the lookup of indexes for the remap table is going wrong.

The xserver uses the remap table slots defined in the dispatch.h exported from
some past version of Mesa, i.e. "#define TexBufferARB_remap_index 174".

Now the remap table is populated from _mesa_init_remap_table in
mesa/main/remap.c, which calls:
_mesa_do_init_remap_table(_mesa_function_pool,
driDispatchRemapTable_size, MESA_remap_table_functions);

Now lets have a look a look into MESA_remap_table_functions[174], which should
have the entry for TexBufferARB, and yes, its there, so everything fine!

But wait, do another test - ClientWaitSync, slot 178 in remap table, at least
if you ask the x server, but slot 185 if you ask Mesa ...

So obviously the remap table is filled with the wrong values.

Regards, Stefan

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to