Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLX: Allow different dispatch tables for different contexts. #85

Closed

Conversation

@kbrenneman
Copy link
Contributor

kbrenneman commented Apr 6, 2016

This is an extension to the libGLX vendor library interface that allows a vendor to provide different dispatch tables for each GLXContext.

It adds two optional callbacks to the __GLXapiImports struct. The first allows the vendor to provide an opaque dispatch table handle for a GLXContext. The second callback is used to populate a dispatch table.

The goal is to allow a library such as Mesa to use libglvnd's dispatch layer instead of having to send every OpenGL function through two layers.

Added two new optional callbacks to __GLXapiImports, which allow a vendor
library to use different dispatch tables for different rendering contexts.

The vendor library can provide an opaque dispatch table handle for each
context, which libGLX.so will use to assign and populate a dispatch table to
use when that context is current.

Incremented the ABI version number for libGLX to 1.1.
if (pEntry->imports.getContextDispatchHandle != NULL
|| pEntry->imports.getContextProcAddress != NULL) {
if (pEntry->imports.getContextDispatchHandle == NULL
|| pEntry->imports.getContextProcAddress == NULL) {

This comment has been minimized.

Copy link
@1ace

1ace Apr 7, 2016

Contributor

I expect some people might not like the number of !, but I'd find that easier to read:

if (!pEntry->imports.getContextDispatchHandle !=
    !pEntry->imports.getContextProcAddress)
@nwnk

This comment has been minimized.

Copy link
Contributor

nwnk commented Apr 12, 2016

I'm not sure I approve? I'd think the better way to handle this would be for Mesa to use GLdispatch and stop using its own copy of glapi. Is that the problem you're trying to address?

@kbrenneman

This comment has been minimized.

Copy link
Contributor Author

kbrenneman commented Apr 12, 2016

I'm not sure I approve? I'd think the better way to handle this would be for Mesa to use GLdispatch and stop using its own copy of glapi. Is that the problem you're trying to address?

That's what the goal is -- Mesa can provide different dispatch tables for different contexts to libglvnd, instead of using its own glapi layer.

libGLdispatch itself is purely internal, though, so vendor libraries only deal with it indirectly through the libGLX interface.

libGLdispatch also only deals with dispatch tables, not contexts. libGLX is responsible for keeping track of contexts and figuring out how to map each context to a dispatch table.

@evelikov

This comment has been minimized.

Copy link
Contributor

evelikov commented Apr 25, 2016

Yes and no. Yes - it would be great to nuke mesa glapi, as GLdispatch is a mere copy of it. And no, the proposed solution does not help.

In mesa the dri module (think of is as a generic driver) is free of all the winsys specifics. Due to that it cannot call into any winsys specific loader (as some of us call it) - libGL/libGLX_mesa/libEGL/libgbm (and let's not forget the xserver one).

Can we promote the GLdispatch API for vendors to use ? Otherwise they're bound to reimplement it in their drivers. From a quick look at the AMD closed source implementation is seems to be based on mesa, so I'm pretty sure they'll be up for the idea ;-)

Humble invite:
Can we move to fd.o mailing list and hosting ? Batting's github's interface is a bit suboptimal.

Bugzilla and Patchwork can added if you guys are keen on them.

@kbrenneman

This comment has been minimized.

Copy link
Contributor Author

kbrenneman commented Apr 25, 2016

Anything we do would have to go through the libGLX or libEGL library, since that's what keeps track of the current context. Exposing the GLdispatch interface directly to the vendor library would mangle GLX's bookkeeping. Especially once we need to worry about whether EGL or GLX has a current context on any given thread.

Unless I misunderstand something, though, the DRI module shouldn't need to call into anything -- libGLX calls into libGLX_mesa to populate a dispatch table. libGLX_mesa could then call into the DRI module.

As for a fd.o mailing list or repo, I wouldn't necessarily object, but let's move that discussion out of the bug report.

@evelikov

This comment has been minimized.

Copy link
Contributor

evelikov commented Apr 25, 2016

Anything we do would have to go through the libGLX or libEGL library, since that's what keeps track of the current context. Exposing the GLdispatch interface directly to the vendor library would mangle GLX's bookkeeping.

Interesting do you have some concrete pointers where I can take a look ?

Especially once we need to worry about whether EGL or GLX has a current context on any given thread.

I think that this should work fine with mesa. Need to check exactly how things are done, and well see if we can reuse the approach.

Unless I misunderstand something, though, the DRI module shouldn't need to call into anything -- libGLX calls into libGLX_mesa to populate a dispatch table. libGLX_mesa could then call into the DRI module.

There are multiple places within the DRI module where the current context is unknown, thus we need to call into glapi. Not entirely sure why/how but it just is - that's another thing to look into.
In some places the DRI module alters the overwrites/restores the entries, I believe it was done in the context of vbos. Don't quote me on that one though.

@kbrenneman

This comment has been minimized.

Copy link
Contributor Author

kbrenneman commented Apr 25, 2016

__glDispatchMakeCurrent and __glDispatchLoseCurrent are used to record both the dispatch table and the current context structure in TLS. If a vendor library tried to call either of those functions directly, then libGLX's would lose its current context state for that thread.

That said, I think it should be possible to change the dispatch table outside of a MakeCurrent call without replacing the rest of the current context struct. That would probably still need to go through libGLX and libEGL, but we can at least provide a similar interface between the two.

The cleanest way I can think of to do that would be to let the vendor library call into libGLX to allocate and free dispatch tables, probably just as opaque handles with GetProcAddress-style callbacks. We'd probably also need a callback into the vendor library to ask for the dispatch table to start with from a glXMakeCurrent call.

@kbrenneman

This comment has been minimized.

Copy link
Contributor Author

kbrenneman commented Sep 27, 2019

Closing. If we still need (or want) something like this, I'll need to update the changes to match the current code.

@kbrenneman kbrenneman closed this Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.