[Mesa-dev] [RFC] Vendor-neutral dispatch library for OpenGL

[Kyle Brenneman]

On 10/06/2015 12:43 PM, Emil Velikov wrote:
> On 6 October 2015 at 16:39, Kyle Brenneman <kbrenneman at nvidia.com> wrote:
>> On 10/06/2015 07:34 AM, Emil Velikov wrote:
>>> 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.
>> 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.
>>
> 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.
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.

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?
>>>    * (Slightly out of scope here) Has there been any plans to have an
>>> interop between vendors' GL implementations ? I am leaning towards
>>> 'nearly impossible' and 'with limited to no interest from the
>>> different vendors'.
>> It hasn't come up yet. Most of the design focuses on keeping the different
>> vendor libraries separate from one another.
>>
>> My first inclination would be that any form of interop between vendor
>> libraries would be outside the scope of libglvnd itself. Without a specific
>> case for how that should work (for example, how a vendor library finds and
>> decides which other vendor library to talk to), it's better left as a
>> separate interface.
>>
> I was wondering if it was worth mentioning this, with Vulkan in the
> works. Afaict, the latter of which should support these kind of
> things, out of the box.
>
>>>    * There was an idea to expose separate libOpenGL libraries, one for
>>> each (major?) GL version.
>>> What happened on that front ?
>> 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?
>>
> 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.
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. 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.

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. 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.

>>>    * 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 ?
>> 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?
>>
> 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.
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, or it might only offer indirect 
rendering with no hardware-specific support.

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.
>
> Cheers,
> Emil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151006/7a7fc653/attachment.html>