-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFE4LyVX1gOwKyEAw8RAniLAJ9lllCyzdVbEuUeatW0Z8QEKcwopwCfaefX
t/W8hk3VAtSaWQZPEzkRWM4=
=CZZW
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
