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

[Emil Velikov]

On 24 November 2015 at 20:22, Kyle Brenneman  wrote:
> On 11/13/2015 12:50 PM, Kyle Brenneman wrote:

> I agree that a separate directory from the other GL headers would be best.
> I'm leaning toward putting the libglvnd headers into a sibling directory to
> the GL headers, probably /usr/include/GLVND.
>
> Putting them in a subdirectory under GL (/usr/include/GL/GLVND) would also
> be an option. But eventually, libglvnd will have an EGL header there as
> well, and putting that under /usr/include/GL seems less appropriate.
>
> Does that sound like a good place for them?
>
>
> Does anyone have any thoughts or opinions on this?
>
Sorry about the delay. I've missed your previous email.

Keeping GLVND and GL, EGL, etc. separate sounds like the better
option. I kind of hinted about that earlier :-P

But seriously, I'm not sure about the exact state glvnd itself
although I will be taking a closer look one the mesa side. I'm afraid
that I have a few other items on my todo list before that.

Thanks
Emil

P.S. Hmmm Gmail seems unhappy with flowed format emails :-(
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kyle Brenneman]

On 11/13/2015 12:50 PM, Kyle Brenneman wrote:

On 10/08/2015 12:29 PM, Emil Velikov wrote:

On 06/10/15 20:58, Kyle Brenneman wrote:

On 10/06/2015 12:43 PM, Emil Velikov wrote:

On 6 October 2015 at 16:39, Kyle Brenneman  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.


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 ?


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?

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]
I agree that a separate directory from the other GL headers would be 
best. I'm leaning toward putting the libglvnd headers into a sibling 
directory to the GL headers, probably /usr/include/GLVND.


Putting them in a subdirectory under GL (/usr/include/GL/GLVND) would 
also be an option. But eventually, libglvnd will have an EGL header 
there as well, and putting that under /usr/include/GL seems less 
appropriate.


Does that sound like a good place for them?


Does anyone have any thoughts or opinions on this?

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kyle Brenneman]

On 11/24/2015 02:49 PM, Emil Velikov wrote:

On 24 November 2015 at 20:22, Kyle Brenneman  wrote:

On 11/13/2015 12:50 PM, Kyle Brenneman wrote:
I agree that a separate directory from the other GL headers would be best.
I'm leaning toward putting the libglvnd headers into a sibling directory to
the GL headers, probably /usr/include/GLVND.

Putting them in a subdirectory under GL (/usr/include/GL/GLVND) would also
be an option. But eventually, libglvnd will have an EGL header there as
well, and putting that under /usr/include/GL seems less appropriate.

Does that sound like a good place for them?


Does anyone have any thoughts or opinions on this?


Sorry about the delay. I've missed your previous email.

Keeping GLVND and GL, EGL, etc. separate sounds like the better
option. I kind of hinted about that earlier :-P

But seriously, I'm not sure about the exact state glvnd itself
although I will be taking a closer look one the mesa side. I'm afraid
that I have a few other items on my todo list before that.

Thanks
Emil

P.S. Hmmm Gmail seems unhappy with flowed format emails :-(
Okay, I'll use a sibling directory for now, then. It'll be easy enough 
to change later if need be, and a pkgconfig file should make it easy for 
other builds to deal with any changes.


I also still need to update the example libglvnd-based Mesa to match the 
changes to libglvnd itself. I'll try to get that done by today or 
tomorrow, though.


-Kyle
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kyle Brenneman]

On 10/08/2015 12:29 PM, Emil Velikov wrote:

On 06/10/15 20:58, Kyle Brenneman wrote:

On 10/06/2015 12:43 PM, Emil Velikov wrote:

On 6 October 2015 at 16:39, Kyle Brenneman  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.


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 ?


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?

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]
I agree that a separate directory from the other GL headers would be 
best. I'm leaning toward putting the libglvnd headers into a sibling 
directory to the GL headers, probably /usr/include/GLVND.


Putting them in a subdirectory under GL (/usr/include/GL/GLVND) would 
also be an option. But eventually, libglvnd will have an EGL header 
there as well, and putting that under /usr/include/GL seems less 
appropriate.


Does that sound like a good place for them?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kyle Brenneman]

On 10/08/2015 08:44 PM, Michel Dänzer wrote:

On 07.10.2015 04:58, Kyle Brenneman wrote:

On 10/06/2015 12:43 PM, Emil Velikov wrote:

On 6 October 2015 at 16:39, Kyle Brenneman  wrote:

On 10/06/2015 07:34 AM, Emil Velikov wrote:

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

Actually, it can't: the amdgpu kernel driver is not only supported by
the Mesa radeonsi driver but will also be supported by future versions
of the Catalyst OpenGL driver. Either OpenGL driver will work with both
the xf86-video-amdgpu driver and the generic modesetting Xorg driver.



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.

I hope we can handle the above scenario as well, allowing to select one
of the supported OpenGL drivers for each application without having to
resort to manipulating symlinks, e.g. via configuration files and/or
environment variables. I think something like Mesa's driconf
infrastructure would be nice for this from a user perspective, it allows
making persistent per-application configuration.


The symlinks idea is more for the reverse of that scenario. When you've 
got multiple server-side display drivers that all call for the same 
client-side vendor library, then you can add symlinks so that each name 
gets you the same library. There's no variation on configuration in that 
case, so the installer or package manager would just create the symlinks 
and leave it at that.


If there are multiple possible vendor libraries for a single display 
driver, then it would need some way to select one. On the server side, 
you can set an X config option to override the vendor name that the 
x11glvnd extension sends back, and on the client side you can set an 
environment variable that would override the vendor library selection in 
libGLX. Both of those require manual configuration, though.


For simple cases where two vendor libraries might be available, but 
you'd always want to pick one over the other, it might be possible for 
the x11glvnd extension to send back multiple names, assuming there was 
some way to figure out what those names should be.


But, I think a config file of some sort would be a better overall 
solution. It would be more flexible, and would lend itself better to 
per-application configuration.


Also note that the vendor library selection logic is internal to libGLX, 
so we can still hammer out the rest of the interface in the meantime.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Michel Dänzer]

On 07.10.2015 04:58, Kyle Brenneman wrote:
> On 10/06/2015 12:43 PM, Emil Velikov wrote:
>> On 6 October 2015 at 16:39, Kyle Brenneman  wrote:
>>> On 10/06/2015 07:34 AM, Emil Velikov wrote:

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

Actually, it can't: the amdgpu kernel driver is not only supported by
the Mesa radeonsi driver but will also be supported by future versions
of the Catalyst OpenGL driver. Either OpenGL driver will work with both
the xf86-video-amdgpu driver and the generic modesetting Xorg driver.


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

I hope we can handle the above scenario as well, allowing to select one
of the supported OpenGL drivers for each application without having to
resort to manipulating symlinks, e.g. via configuration files and/or
environment variables. I think something like Mesa's driconf
infrastructure would be nice for this from a user perspective, it allows
making persistent per-application configuration.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 06/10/15 20:58, Kyle Brenneman wrote:
> On 10/06/2015 12:43 PM, Emil Velikov wrote:
>> On 6 October 2015 at 16:39, Kyle Brenneman  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.
> 
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 ?

> 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?
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]
   * 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.
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 

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

[Kyle Brenneman]

On 10/08/2015 12:29 PM, Emil Velikov wrote:

On 06/10/15 20:58, Kyle Brenneman wrote:

On 10/06/2015 12:43 PM, Emil Velikov wrote:

On 6 October 2015 at 16:39, Kyle Brenneman  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.


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 ?


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?

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]

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

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.


As long as the set of
exported functions stays consistent between versions, then a 

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

[Emil Velikov]

On 6 October 2015 at 16:39, Kyle Brenneman  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.

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

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

Cheers,
Emil

Re: [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  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 

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

[Emil Velikov]

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.

 * (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'.

 * There was an idea to expose separate libOpenGL libraries, one for
each (major?) GL version.
What happened on that front ?

 * 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 ?

 * The POC code at github looks quite good and consistent.
Here are a few bits, in case you're interested.
- We're building either libGLX_mesa or libGL, but never both.
- Lovely interactions with --with-gl-lib-name. Perhaps we should
remove the latter.
- Insanely long lines and other coding style nitpicks.
- 'Export what you need'


Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kyle Brenneman]

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.



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




  * 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?




  * 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 POC code at github looks quite good and consistent.
Here are a few bits, in case you're interested.
- We're building either libGLX_mesa or libGL, but never both.
- Lovely interactions with --with-gl-lib-name. Perhaps we should
remove the latter.
- Insanely long lines and other coding style nitpicks.
- 'Export what you need'


Cheers,
Emil


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Roland Scheidegger]

FWIW from a high level point of view this makes all sense to me. It is
however definitely not my field of expertise, but whatever makes it
easier to have multiple drivers installed is imho a good thing...
Some more feedback from mesa people which are more familiar with the gl
api dispatch stuff (albeit there's probably not that many...) would
probably be nice...

Roland

Am 30.09.2015 um 22:07 schrieb Kyle Brenneman:
> I'm working on libglvnd, a vendor-neutral dispatch library for OpenGL,
> and I wanted to see if anyone had any comments or suggestions about it.
> Right now, I'm trying to get the GLX interface wrapped up, but I'd like
> to get some feedback from the Mesa community before I'd be confidant in
> calling it ready.
> 
> A bit of background: Libglvnd was originally proposed back at XDC 2013.
> It's hosted on Github here:
> https://github.com/NVIDIA/libglvnd
> 
> The goal for libglvnd is to allow multiple OpenGL implementations from
> different vendors to coexist on the same system, without interfering
> with each other or requiring any manual configuration.
> 
> With libglvnd, libGL.so is a vendor-independent dispatch library, not
> part of any driver. Each vendor provides its OpenGL implementation in a
> separate library. An application still links to libGL.so just like it
> does now, but then libGL.so will figure out which vendor library to use,
> and will dispatch any OpenGL and GLX calls to that library.
> 
> The libglvnd libraries make as few assumptions as possible about how the
> vendor libraries work, so that (hopefully) it's easy to port any
> existing OpenGL implementation to it. In some cases, a simple wrapper
> library around an existing libGL.so library would be enough.
> 
> As it's currently implemented, libglvnd selects a vendor library for
> each X screen. So, you could have two X screens that each use a
> different vendor library, and a single process could create and use
> rendering contexts on both. It doesn't handle two different vendor
> libraries for the same X screen, although the ABI is set up such that it
> would be possible to add that capability later on.
> 
> The EGL interface is still in its really early design stages. Any
> comments or requirements that I might have forgotten are more than welcome.
> 
> In addition, I've put together a proof-of-concept version of Mesa that
> can use libglvnd. It's still a work in progress, but hopefully it will
> provide a more concrete example of how libglvnd works. I've got it
> checked into Github here:
> https://github.com/kbrenneman/mesa-libglvnd
> 
> Internally, it's broken down into a few different libraries:
> libGLX handles GLX functions, and is responsible for keeping track of
> GLX contexts, selecting and loading vendor libraries, and setting up the
> dispatch table for OpenGL functions. This is the only library that a
> vendor library directly talks to.
> 
> libGLdispatch is responsible for dispatching OpenGL calls to the correct
> library based on the thread's current rendering context. It uses a
> dispatch table derived from Mesa's GLAPI layer. libGLdispatch is purely
> internal -- the vendor libraries go through libGLX to set up dispatch
> tables, and an application would call into libGL.so or libOpenGL.so to
> call any OpenGL functions.
> 
> libGL.so is a wrapper around libGLX and libGLdispatch. Conceptually, it
> just exports GL and GLX functions and forwards them to libGLX and
> libGLdispatch to deal with. The implementation is a bit more complicated
> to avoid the overhead of an extra indirect jump every time an app calls
> an OpenGL function.
> 
> In addition, there's a new library, libOpenGL.so. It's basically the
> same as libGL.so, except that it only exports the OpenGL functions, not
> GLX. It also doesn't depend on libGLX, so it could also be used with an
> EGL or GLX application. The hope is that future applications will link
> against libOpenGL.so and either libGLX.so or libEGL.so. This makes for a
> cleaner separation of OpenGL from the window system binding. But,
> libGL.so will be kept around indefinitely for backwards compatibility.
> 
> Comments, questions, and suggestions are all welcome.
> 
> Thanks,
> -Kyle Brenneman
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kyle Brenneman]

I'm working on libglvnd, a vendor-neutral dispatch library for OpenGL, 
and I wanted to see if anyone had any comments or suggestions about it. 
Right now, I'm trying to get the GLX interface wrapped up, but I'd like 
to get some feedback from the Mesa community before I'd be confidant in 
calling it ready.


A bit of background: Libglvnd was originally proposed back at XDC 2013. 
It's hosted on Github here:

https://github.com/NVIDIA/libglvnd

The goal for libglvnd is to allow multiple OpenGL implementations from 
different vendors to coexist on the same system, without interfering 
with each other or requiring any manual configuration.


With libglvnd, libGL.so is a vendor-independent dispatch library, not 
part of any driver. Each vendor provides its OpenGL implementation in a 
separate library. An application still links to libGL.so just like it 
does now, but then libGL.so will figure out which vendor library to use, 
and will dispatch any OpenGL and GLX calls to that library.


The libglvnd libraries make as few assumptions as possible about how the 
vendor libraries work, so that (hopefully) it's easy to port any 
existing OpenGL implementation to it. In some cases, a simple wrapper 
library around an existing libGL.so library would be enough.


As it's currently implemented, libglvnd selects a vendor library for 
each X screen. So, you could have two X screens that each use a 
different vendor library, and a single process could create and use 
rendering contexts on both. It doesn't handle two different vendor 
libraries for the same X screen, although the ABI is set up such that it 
would be possible to add that capability later on.


The EGL interface is still in its really early design stages. Any 
comments or requirements that I might have forgotten are more than welcome.


In addition, I've put together a proof-of-concept version of Mesa that 
can use libglvnd. It's still a work in progress, but hopefully it will 
provide a more concrete example of how libglvnd works. I've got it 
checked into Github here:

https://github.com/kbrenneman/mesa-libglvnd

Internally, it's broken down into a few different libraries:
libGLX handles GLX functions, and is responsible for keeping track of 
GLX contexts, selecting and loading vendor libraries, and setting up the 
dispatch table for OpenGL functions. This is the only library that a 
vendor library directly talks to.


libGLdispatch is responsible for dispatching OpenGL calls to the correct 
library based on the thread's current rendering context. It uses a 
dispatch table derived from Mesa's GLAPI layer. libGLdispatch is purely 
internal -- the vendor libraries go through libGLX to set up dispatch 
tables, and an application would call into libGL.so or libOpenGL.so to 
call any OpenGL functions.


libGL.so is a wrapper around libGLX and libGLdispatch. Conceptually, it 
just exports GL and GLX functions and forwards them to libGLX and 
libGLdispatch to deal with. The implementation is a bit more complicated 
to avoid the overhead of an extra indirect jump every time an app calls 
an OpenGL function.


In addition, there's a new library, libOpenGL.so. It's basically the 
same as libGL.so, except that it only exports the OpenGL functions, not 
GLX. It also doesn't depend on libGLX, so it could also be used with an 
EGL or GLX application. The hope is that future applications will link 
against libOpenGL.so and either libGLX.so or libEGL.so. This makes for a 
cleaner separation of OpenGL from the window system binding. But, 
libGL.so will be kept around indefinitely for backwards compatibility.


Comments, questions, and suggestions are all welcome.

Thanks,
-Kyle Brenneman

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev