[Mesa-dev] Vendor-neutral OpenGL dispatching library

[Andy Ritger]

(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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev