Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ian Romanick wrote:
>
>> Normally when an application calls glXGetProcAddress a dummy stub is
>> created. In the current implementation, a dispatch offset is not
>> assigned at this time. The existing code expects that the driver will
>> later ask for the function to be added and will provide a dispatch
>> offset. This is actually a bug, and it prevents drivers that support,
>> for example, APPLE_vertex_array_object from working with versions of
>> libGL that don't. Once I commit a fix for that, libGL could assign a
>> dispatch offset when glXGetProcAddress is called.
>>
>> This would allow libGL to create a fully functional dispatch stub on
>> x86. In fact, libGL could create an entire page of dispatch stubs the
>> first time glXGetProcAddress is called. This can be done on x86 because
>> the dispatch function is independent of the parameter signature of the
>> function being dispatched.
>>
>> x86-64 and PowerPC do not share this feature. Since these platforms
>> pass all parameters in registers, the dispatch function for glBegin is
>> different from the dispatch function for glTexImage2D. When
>> glXGetProcAddress is called it is impossible to know what the parameter
>> signature, and thus the contents of the dispatch stub, should be. This
>> prevents those platforms from being able to create a page of dispatch
>> stubs at a time.
>>
>> I guess we could do a single dispatch function per page, but since the
>> dispatch functions are on the order of 128 bytes, that seems awfully
>> wasteful.
>
> I've done some work on this over the past couple days. I should be able
> to post a patch for review that covers at least x86 and x86-64 in the
> next couple days.
>
> I've created a mechanism where a set of bins for dispatch functions are
> created. There is one bin for each possible dispatch function
> configuration. On platforms that do not require register saves in
> dispatch functions, there is one bin. For platforms that require
> register saves (e.g., x86-64 with pthreads), there is one bin per
> register save configuration. On x86-64 with pthreads, this means there
> are (6 + 1) * (8 + 1) = 63 bins. I arrived at this number because
> between 0 and 6 integer registers and between 0 and 8 floating point
> registers must be saved.
>
> There are two cases when a dispatch function is created. A driver can
> ask for a dispatch function (it actually asks for the offset, but both
> are generated at the same time). When requesting a dispatch function,
> the driver supplies a parameter signature, and an optimal bin selection
> can be made. libGL can also ask for a dispatch function when an
> application calls glXGetProcAddress. When libGL requests a function,
> the parameter signature is not available, and a pessimistic bin is selected.
>
> Each bin tracks a page of dispatch functions with pre-assigned dispatch
> offsets. When a function is requested, the next available function in
> the page and its associated dispatch offset is returned. When the last
> function from a page is returned, a new page is allocated and filled
> with functions. This enables all the right mprotect-fu to be done at
> the right times.
>
> There is one catch, and I'm not sure how to resolve it. When a driver
> requests a function, it can request a set of identical functions with
> different names. For example, the driver can request that
> glWindowPos3f, glWindowPos3fARB, and glWindowPos3fMESA be created as
> aliases for each other. All three will share the same dispatch offset
> (very important) and the same dispatch function (not as important).
>
> However, if the application calls glXGetProcAddress("glWindowPos3f")
> *and* glXGetProcAddress("glWindowPos3fARB") before the driver is loaded,
> those functions will have different dispatch offsets. That would be
> bad. This is a silly, but perfectly valid thing for an application to
> do. The app will segfault when it tries to call one of the two
> functions but function correctly when it calls the other. This will
> result in difficult to diagnose bug reports being filed on Mesa.
>
> Any suggestions? If possible, I'd like for this to be resolved for Mesa
> 6.5.1.
Can the two extra/redundant entrypoints be detected and then hardwired
to double-dispatch back to the single, correct entrypoint?
Or set up the redundant dispatch entries to dispatch to a seperate
routine that then bounces back through the dispatch table to the correct
entrypoint?
Keith
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
