On Thu, 2016-12-15 at 17:15 +0900, Michel Dänzer wrote: > Hi Adam, Andy, Kyle, > > > even with GLVND in place and used by Mesa and other GL implementations, > one remaining issue preventing peaceful coexistence of Mesa based and > other GLX implementations is that other GLX implementations tend to ship > their own, mutually incompatible versions of the Xorg glx module. I'm > not sure about all the reasons for this, but an important one is that > the glx module in the xserver tree has been using the DRI driver > interface directly, which can only work with Mesa. > > Adam, IIRC you previously mentioned the possibility of making the > xserver glx module use EGL instead of the DRI driver interface. Another > possibility might be to make it use GLVND. Is my understanding correct > that those are basically two mutually exclusive approaches for > addressing this issue? Maybe there's even more options I'm not aware of?
They are not mutually exclusive. Complementary if anything. Apologies for the long reply. Currently xserver's glx "knows about" the DRI interface in several ways. One is that we query the DRI driver for the list of fbconfigs at server initialization. We could just as easily ask for it from the EGL implementation, assuming we know how to map from the current GLX screen to the corresponding EGL device. (Yes, the correspondence with EGLConfigs is not perfect, but not I suspect in ways that matter.) We also know about the DRI extension interface and wire up certain GLX extensions based on their presence. These are in two classes: features we could infer from equivalent EGL existing features, or features that only apply to actual indirect contexts (EXT_texture_from_pixmap for example). For the latter, I'd imagine another small loadable driver - or perhaps part of the ddx driver in xfree86 - would simply register protocol dispatch functions and the libglx core would handle dispatching to them based on the context tag. Finally, for actual indirect contexts, we use the DRI interface to create and manage them. Clearly we can use eglCreateContext to mirror the context state. The glx driver would supply a callback for drawable creation, to bind window system surfaces in a way that's visible to the proxy context. There'd be another callback for SwapBuffers. I think that's all you'd need to hook from core GLX 1.4, anything else would necessarily be extension requests as above. I think the above would all be an improvement even if we were only considering Mesa on only one screen (although it would necessarily spell doom for DRI1, which Mesa has no EGL backend for nor could it really). Adding glvnd means we could support different vendors' mostly- EGL backends on different screens. Future work could include supporting different vendors' backends on the _same_ screen, for heterogeneous GPU models where each has a disjoint set of outputs and you'd like to swap buffers "near" their output. - ajax _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
