(mesa-dev: please let us know if libglvnd implementation discussion is
inappropriate for this alias)
Hi Brian,
I was thinking about the GetProcAddress'ed GLX entry
point problem the libglvnd implementation highlights:
online-generate-and-resolve-at-MakeCurrent, as suggested in
linux-opengl-abi-proposal.txt, works well for OpenGL entry points that
only have defined meaning when a context is current, but isn't sufficient
for GLX entry points that might have defined meaning even when no context
is current.
In TOT libglvnd, per entry point, we have to call out to the vendor library
to get the parameter_signature for each function. What if, instead,
the flow were like this:
* During GetProcAddress, check getCachedProcAddress(), else return
a _glapi_get_proc_address()-allocated address. I.e., same as today,
except remove __glXGetGLXDispatchAddress().
* When a vendor library is loaded (force-loaded with
__GLX_VENDOR_LIBRARY_NAME, or inferred at the first screen-specific GLX
1.4 entry point), have the vendor library register *all*
GetProcAddress'able function names it supports, along with the
parameter_signature for each.
* During vendor library load time, assuming the vendor library reports
pairs of function names and parameter_signatures, then for each pair:
/* if not already in the cache, allocate a stub, now */
if !getCachedProcAddress(functionName) {
_glapi_get_proc_address(functionName)
}
/* if an offset isn't already allocated, allocate one now */
if (_glapi_get_proc_offset(functionName) == -1) {
_glapi_add_dispatch(functionName, parameter_signature)
patch all existing dispatch tables with the new offset
}
I think the above would avoid some of the complexity of what is currently
in place in libglvnd. It would make vendor library loading even more
heavy-weight, but that is thankfully a rare event. It would still
correctly dispatch GLX extension entry points, as long as a GLX 1.4
entry point was called first (to trigger vendor library loading, and
all the mechanics described above).
Tangentially related: it seems a little inefficient that
_glapi_get_proc_address() will have the 'struct mapi_stub' for a
given function name, but then when we call _glapi_add_dispatch() or
_glapi_get_proc_offset(), those functions have to lookup the 'struct
mapi_stub' for the function name again (stub_find_public() binary
searches through all public functions, and stub_find_dynamic() does a
linear search).
Others on mesa-dev who are more familiar with mapi might have an
opinion, but I wonder if it would be reasonable to have a variant of
_glapi_get_proc_address() that also returns a 'struct mapi_stub', and
then variants of _glapi_add_dispatch() and _glapi_get_proc_offset()
that take a 'struct mapi_stub' rather than (or in addition to) a string.
Thanks,
- Andy
On Wed, Aug 28, 2013 at 08:46:13AM -0700, Brian Nguyen wrote:
> Last September, Andy Ritger proposed updating the Linux OpenGL ABI to allow
> for
> multiple vendors to co-exist within a single process and OpenGL applications
> to
> dispatch commands to different vendors with per-context granularity. The
> current
> proposal [1] calls for a vendor-neutral "API library" which acts as an
> intermediate layer between the application and OpenGL vendor implementations
> that manages this dispatching.
>
> I have written a work-in-progress library based on this proposal which
> implements this API library for GLX. This library leverages some code from
> Mesa's glapi module to handle TLS and core OpenGL dispatching, as well as the
> BSD-licensed uthash library [2] and the X.org Xserver's list.h [3]. The
> library
> source can be found at this location:
>
> http://github.com/NVIDIA/libglvnd
>
> In this repository, the file README.md describes the library's code
> organization
> and architecture as well as remaining open issues and implementation TODOs.
> What do people think about this? We are hoping to gather feedback to help
> facilitate discussion of the implementation of the new ABI during XDC 2013.
> Any concerns, suggestions, or other comments would be much appreciated.
>
> Thanks,
> Brian
>
> [1]
> https://github.com/aritger/linux-opengl-abi-proposal/blob/master/linux-opengl-abi-proposal.txt
> [2] http://troydhanson.github.io/uthash/
> [3]
> http://cgit.freedesktop.org/xorg/xserver/tree/include/list.h?id=74469895e39fa38337f59edd64c4031ab9bb51d8
>
>
>
>
>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may
> contain
> confidential information. Any unauthorized review, use, disclosure or
> distribution
> is prohibited. If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
