<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 10/08/2015 12:29 PM, Emil Velikov wrote: <blockquote cite="mid:5616B625.1050608@gmail.com" type="cite"> <pre wrap="">On 06/10/15 20:58, Kyle Brenneman wrote: </pre> <blockquote type="cite"> <pre wrap="">On 10/06/2015 12:43 PM, Emil Velikov wrote: </pre> <blockquote type="cite"> <pre wrap="">On 6 October 2015 at 16:39, Kyle Brenneman <a class="moz-txt-link-rfc2396E" href="mailto:kbrenneman@nvidia.com"><kbrenneman@nvidia.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 10/06/2015 07:34 AM, Emil Velikov wrote: </pre> <blockquote type="cite"> <pre wrap="">Hello Kyle, A few questions/points of discussion: * What is your take on having a libglvnd 'package', which provides the headers (and maybe other materials), apart from the libraries ? I'm basically thinking about OpenGL.h, GLX.h, etc for programs that wish to use new ABI, and glvnd{Foo,Bar}.h which mesa and other GL implementations. </pre> </blockquote> <pre wrap="">I haven't looked much into packaging yet. I'm open to any suggestions that might make that easier, though. One thing that I'm planning to do but haven't gotten to yet is to move the public headers into a separate directory. There's a couple of header files (libglxabi.h and GLdispatchABI.h) that are intended to be used by vendor library implementations, and the other headers are all internal. The headers that you'd use for compiling an application (gl.h, glx.h, etc.) could easily go into a separate package, too. </pre> </blockquote> <pre wrap="">By 'packaging' I meant that the relevant files are available after `make install'. Currently for GLdispatchABI.h and others that's not the case. We can leave it up-to the distributions to manage the actual packages (if in doubt a document to guide them), but we can make sure that the files (including pkg-config and cmake ones, separate set for user/developer) are there. </pre> </blockquote> <pre wrap="">The 'make install' command currently doesn't do anything with the regular GL headers. I would expect that if someone's building an OpenGL application, then they've probably already installed some version of the GL headers separately. Still, I could probably add a configure option or something to include them. </pre> </blockquote> <pre wrap="">Pretty much what I was wondering. Mostly as I've noticed that the official Nvidia driver has started shipping some headers which clash with mesa ones :'( Perhaps the AMD proprietary driver ships some as well ? </pre> <blockquote type="cite"> <pre wrap="">Including the public ABI headers in a "make install" does sound like a good idea. Maybe put them next to the normal GL headers, or under a GLVND subdirectory? </pre> </blockquote> <pre wrap="">A separate location sounds better imho. Then again this information will be made available via the .pc .cmake files. People that don't use them can hardcode thing as needed :) [snip] </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> * There was an idea to expose separate libOpenGL libraries, one for each (major?) GL version. What happened on that front ? </pre> </blockquote> <pre wrap="">Nothing as far as I know. However, each of those libraries is basically just a thin wrapper around libGLdispatch.so, so in theory you could define any number of libraries that just export a different set of functions. It's more a question of how many libraries we'd want to deal with. >From an application standpoint, having a fixed set of libraries with a known set of exported functions seems like the easiest option, since you could then link your application against it and not have to modify it later. That said, the set of functions to export from libGL.so and libOpenGL.so is still an open question. The set right now is just what libglvnd inherited from Mesa, but it would be good to have a more clearly-defined set. Maybe something simple like all core OpenGL functions through version 4.5 or so? </pre> </blockquote> <pre wrap="">I'm rather inclined towards "(ideally) no GL symbols should be statically available" - just use *gl*GetProcAddress. Otherwise thing are bound to get quite hairy. - Forward/backward compatibility - Incorrectly linked - program uses GL N, yet linked against GL N+1. - Developer confusion - which library do I need, how do I check for X and not Y. - The easy way out - using GL N core function glFoo, link against GL N, rather than LG N-1 + doing the extension check. Note that libGL.so from older mesa was exposing a few too many symbols statically, so we might want to make sure these/similar changes landed in libglvnd. </pre> </blockquote> <pre wrap="">libGLX.so itself only exports GLX 1.4 functions -- no extensions and no OpenGL functions. If an app developer wants to, they could link against only libGLX.so, and then use glXGetProcAddress to look up every OpenGL function. libOpenGL.so is there to avoid the hassle of having looking up every OpenGL function, especially in simpler apps that don't need to use many extension functions. Developer confusion is why I think it would be best to define a set of functions to export and just stick with it. </pre> </blockquote> <pre wrap="">Greater confusion will come with the various different lists, imho. Esp. since there will be some overlap but they (the lists) won't be quite the same between the old and new ABI. It would be easier to have a macro/helper that fetches any entry point required via gl*GetProcAddress, rather having divergent flow based on heuristics X. See for example how GLEW does not always get it right, thus libepoxy was born. I suspect a similar thing will happen for the new ABI. </pre> <blockquote type="cite"> <pre wrap="">As long as the set of exported functions stays consistent between versions, then a developer can rely on it without getting missing or duplicate symbol errors every time a new libglvnd version comes along. </pre> </blockquote> <pre wrap="">This will work mainly for the experienced developers. For newcommers (people doing small apps), this is bound to cause serious headache. If the general consensus is in favour of the static exports, then I would strongly suggest: - No libOpenGL for GL X and another for Y. Just have a single library. Otherwise you'll get into the issues mentioned earlier. - libglvnd tests need to ensure no extra symbols get exported. </pre> <blockquote type="cite"> <pre wrap="">For backward compatibility with existing applications, libGL.so and libGLES*.so would still need to be there, but those might have a different set of exports than libOpenGL.so. </pre> </blockquote> <pre wrap="">This will lead to even further confusion, imho. Think of the case - am I using the old or the new ABI, did which symbols did that one exported again... Ahh yes, not the ones available in the old ABI :\ </pre> <blockquote type="cite"> <pre wrap="">By the spec, libGL.so only exports OpenGL 1.2 functions, but most libGL.so implementations out there export a lot more, and some buggy apps depend on that. </pre> </blockquote> <pre wrap="">If you don't export any, there is no way for people to unintentionally {ab,}use it. Starting off clean would be great imho. I won't babble any more on the topic. Hopefully my ideas/concerns came across without being too pedantic. </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> * The existing x11glvnd extension seems to be a "xserver only" approach. Iirc at XDC last year, people were leaning towards using an FD to obtain all the information needed. Currently mesa/xserver uses that to detect if we should load i915, i965, r300, r600... driver. What's your take on this ? </pre> </blockquote> <pre wrap="">I'm open to alternatives, but I'm not familiar with the FD approach you're describing. Can you give me more details about it, or point me at where in the Mesa code it is? </pre> </blockquote> <pre wrap="">The idea is that you can get the device(node) fd from the server (x,weston,foo) and use that to communicate with the module and/apply any form of heuristics. Currently mesa has a few: - get the kernel module name (via ioctls or sysfs) and map it to the userspace driver. - get the vendor/device pciid (via libudev or sysfs), and map it to the userspace driver. The code is in src/loader, it's a bit hard to look at, so be warned. I've been planning to nuke the ioctl vs sysfs vs libudev, by pushing the chaos to libdrm. So that others can reuse it when needed. yet it's not the most interesting thing to do bth. </pre> </blockquote> <pre wrap="">The only thing that libGLX can assume is that each X screen corresponds to at most one vendor library. A vendor library might be libdrm-based or might not. It might be a purely software-based implementation that doesn't even use the GLX extension, </pre> </blockquote> <pre wrap="">I'm confused - isn't x11glvnd suppose to communicate with libGLX ? How can that happen if there is no GLX extension ?</pre> </blockquote> The x11glvnd extension is independant of the GLX extension. The only thing that x11glvnd does is map a drawable to a screen number, and map a screen number to a vendor name. The drawable-to-screen mapping is so that libGLX can figure out what to do with a regular X window, since it wouldn't have created it. The screen-to-vendor mapping is so that libGLX can figure out which vendor library to load for each screen. Using libGLX with a server that doesn't support the GLX extension is still possible (modulo error reporting), if the vendor library allows it. <blockquote cite="mid:5616B625.1050608@gmail.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">or it might only offer indirect rendering with no hardware-specific support. </pre> </blockquote> <pre wrap="">Completely forgot about indirect rendering. We sort of swept it under the rug with dri3 and I'm pretty sure many of us (ajax?) won't miss it much.</pre> </blockquote> For the most part, indirect rendering isn't any different than any other vendor library. The only case where it needs special attention is that if you're connected to a remote X server, then you can't rely on the x11glvnd extension -- the remote server might not support it, or it might send back a vendor name that doesn't match any available library. To deal with that, libGLX looks for a fallback vendor library. Right now, that's just a symlink to another vendor, but eventually the plan is to have an indirect rendering implementation included in libglvnd itself. Once we've got an indirect rendering library, though, that means every other vendor can skip indirect rendering support and just let libglvnd handle it. <blockquote cite="mid:5616B625.1050608@gmail.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">The x11glvnd extension will (by default) hand back the name of whatever video driver is driving a screen. For cases where multiple vendor names should all use the same vendor library, all the different names would just be symlinks to the same library. So for example, you might have have libGLX_mesa.so as the library, and then you'd have symlinks to it named libGLX_intel.so, libGLX_vesa.so, and so on. </pre> </blockquote> <pre wrap="">From a similar 'symlink alike' solution in mesa I must say that the end result is not as appealing as the original idea. I'm rather biased on the topic I'd refer it to others to cast their views. Thanks Emil </pre> </blockquote> </body> </html>