SDL 2.0 OpenGL support completely broken on Linux?

Hey guys,

I’ve tried to play around with the current SDL 2.0 builds (yeah, I know it’s still far from being stable), but I’ve noticed that neither the packaged build on the libsdl.org site nor the current Mercurial revisions are able to create an SDL window with OpenGL support enabled.

To ensure my stupidity is not the actual problem I tried running this (http://www.opengl.org/wiki/Tutorial1:Creating_a_Cross_Platform_OpenGL_3.2_Context_in_SDL%28C_/_SDL%29) example, resulting in the following errors:

Code:
libEGL warning: DRI2: failed to authenticate
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/xorg/modules/dri)
Unable to create window:

Three things are irritating here. First: Why is SDL_CreateWindow() complaining about some EGL stuff, which I suppose is OpenGL ES, when I don’t even want to use it?
Second: If I remove the SDL_WINDOW_OPENGL flag, then of course an OpenGL context cannot be created, but SDL_CreateWindow manages to create a window.
Third: SDL doesn’t actually throw an error message. The only thing it does is return a nullptr.

In case that helps, relevant data about my system:
OS: Arch Linux 64 bit, with Kernel 3.4.4
Video card: NVidia GeForce 9800 GT, with latest 302.17 drivers on X.org Server 1.12.3

So… has the way we need to use the new API changed or is it just some general bug in the current code?

When you build SDL with both GLX and EGL support, the driver will always use the EGL calls. Currently he only option is to configure SDL with the --disable-video-opengles switch.

Tnaks, that did the trick.

I observed this behavior too, really annoying.On 07/12/2012 01:19 AM, mbentrup wrote:

When you build SDL with both GLX and EGL support, the driver will always use the EGL calls. Currently he only option is to configure SDL with the --disable-video-opengles switch.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Umh, is there a bug report filed about this?
VittorioOn Fri, Jul 13, 2012 at 5:43 AM, Forest Hale wrote:

I observed this behavior too, really annoying.

On 07/12/2012 01:19 AM, mbentrup wrote:

When you build SDL with both GLX and EGL support, the driver will always use the EGL calls. Currently he only option is to configure SDL with the --disable-video-opengles switch.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’ll try and frame the problem a bit better. In the X11 driver, the
SDL_VideoDevice has several slots for GL-related function pointers,
which are made accessible through methods such as SDL_GL_LoadLibrary.
Building with EGL enabled will always fill the slots with X11_GLES_
functions (by virtue of being second in line), with no way of
overriding. Which would be a problem.

Let’s think about a program that uses straight GL commands through
SDL. Depending on how you’ve built it, GLX or EGL is loaded by SDL at
runtime. Apps use this SDL linked library to manage the context (e.g.
stuff like glxMakeCurrent), but a compile-time linked library to do
the actual work (e.g. stuff like glTexImage2D). Of course, if SDL sets
up a GLX context, and your program starts demanding GLESv2 to do some
painting, it’s not going to work properly.

Ideally you’d want to be able to compile both GLX and EGL support into
the library, have GLX as the default choice, and provide an optional
mechanism for asserting (not suggesting) whether you want GLX or EGL
to be used by SDL’s context manager. I’m not certain of the best place
for this; right now the functions are set up in X11_CreateDevice,
which is called by SDL_VideoInit. Maybe create a new SDL_GLattr called
something like SDL_GL_CONTEXT_EGL?On Fri, Jul 13, 2012 at 3:22 PM, Vittorio Giovara <vitto.giova at yahoo.it> wrote:

Umh, is there a bug report filed about this?
Vittorio

On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale wrote:

I observed this behavior too, really annoying.

On 07/12/2012 01:19 AM, mbentrup wrote:

When you build SDL with both GLX and EGL support, the driver will always use the EGL calls. Currently he only option is to configure SDL with the --disable-video-opengles switch.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it>

Umh, is there a bug report filed about this?
Vittorio

I observed this behavior too, really annoying.

When you build SDL with both GLX and EGL support, the driver will
always use the EGL calls. Currently he only option is to configure SDL with
the --disable-video-opengles switch.

It’s filed here:

http://bugzilla.libsdl.org/show_bug.cgi?id=1428

I talked to Sam about this a while ago, we agreed that when both backends
are available, an environment variable should be used to determine which
one to prefer. I haven’t had time to work on this yet though.> On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale wrote:

On 07/12/2012 01:19 AM, mbentrup wrote:


Gabriel.

Patches are welcome!On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo wrote:

2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it>

Umh, is there a bug report filed about this?
Vittorio

On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale wrote:

I observed this behavior too, really annoying.

On 07/12/2012 01:19 AM, mbentrup wrote:

When you build SDL with both GLX and EGL support, the driver will
always use the EGL calls. Currently he only option is to configure SDL with
the --disable-video-opengles switch.

It’s filed here:

http://bugzilla.libsdl.org/show_bug.cgi?id=1428

I talked to Sam about this a while ago, we agreed that when both backends
are available, an environment variable should be used to determine which
one to prefer. I haven’t had time to work on this yet though.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’d disagree that an environment variable would be a good way of doing
it… I understand that’s how it’s done with the audio backend, but
with GL it’s different; your app directly links to the GL/GLES library
for draw calls, so depending how it was built it needs a certain
backend to work properly. By contrast the audio API wraps almost
everything; you don’t use the SDL audio APIs to set up the sound, then
throw in a bunch of calls directly to the PulseAudio library to adjust
the panning.

Moving house this weekend, but I’ll try and make a patch if I get some
spare time.On Sat, Jul 14, 2012 at 9:11 AM, Sam Lantinga wrote:

Patches are welcome!

On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo wrote:

2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it>

Umh, is there a bug report filed about this?
Vittorio

On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale wrote:

I observed this behavior too, really annoying.

On 07/12/2012 01:19 AM, mbentrup wrote:

When you build SDL with both GLX and EGL support, the driver will
always use the EGL calls. Currently he only option is to configure SDL with
the --disable-video-opengles switch.

It’s filed here:

http://bugzilla.libsdl.org/show_bug.cgi?id=1428

I talked to Sam about this a while ago, we agreed that when both backends
are available, an environment variable should be used to determine which one
to prefer. I haven’t had time to work on this yet though.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think this is a really good point. I’d rather fail gently if GL ES 2.0
wasn’t found and my app used that. Crashing seems like a less than graceful
experience.

PatrickOn Sat, Jul 14, 2012 at 12:42 AM, Scott Percival <scott at labyrinthdata.net.au wrote:

I’d disagree that an environment variable would be a good way of doing
it… I understand that’s how it’s done with the audio backend, but
with GL it’s different; your app directly links to the GL/GLES library
for draw calls, so depending how it was built it needs a certain
backend to work properly. By contrast the audio API wraps almost
everything; you don’t use the SDL audio APIs to set up the sound, then
throw in a bunch of calls directly to the PulseAudio library to adjust
the panning.

Moving house this weekend, but I’ll try and make a patch if I get some
spare time.

On Sat, Jul 14, 2012 at 9:11 AM, Sam Lantinga wrote:

Patches are welcome!

On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo wrote:

2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it>

Umh, is there a bug report filed about this?
Vittorio

On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale wrote:

I observed this behavior too, really annoying.

On 07/12/2012 01:19 AM, mbentrup wrote:

When you build SDL with both GLX and EGL support, the driver will
always use the EGL calls. Currently he only option is to configure
SDL with

the --disable-video-opengles switch.

It’s filed here:

http://bugzilla.libsdl.org/show_bug.cgi?id=1428

I talked to Sam about this a while ago, we agreed that when both
backends

are available, an environment variable should be used to determine
which one

to prefer. I haven’t had time to work on this yet though.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’ve written a patch[1] that implements the environment variable
solution, but I agree that it’s not ideal. The problem is that, at
present, the API doesn’t seem to make any distinction between OpenGL and
OpenGL ES at all, and certainly no distinction between versions of
OpenGL ES. (If I’m wrong, please correct me!) The cleanest solution,
IMHO, would be to add a new window flag SDL_WINDOW_OPENGLES to be used
instead of SDL_WINDOW_OPENGL. This is not backwards-compatible, and
touches a lot more than just X11. Other options could be adding an
attribute for API version, but that doesn’t seem as neat.

As a point of interest, ‘testgles’ works fine with desktop OpenGL (there
are no ES-only calls).

Cheers,

– David

[1] http://bugzilla.libsdl.org/show_bug.cgi?id=1428On 15/07/12 23:26, Patrick Baggett wrote:

I think this is a really good point. I’d rather fail gently if GL ES
2.0 wasn’t found and my app used that. Crashing seems like a less than
graceful experience.

Patrick

On Sat, Jul 14, 2012 at 12:42 AM, Scott Percival <scott at labyrinthdata.net.au <mailto:scott at labyrinthdata.net.au>> wrote:

I'd disagree that an environment variable would be a good way of doing
it... I understand that's how it's done with the audio backend, but
with GL it's different; your app directly links to the GL/GLES library
for draw calls, so depending how it was built it _needs_ a certain
backend to work properly. By contrast the audio API wraps almost
everything; you don't use the SDL audio APIs to set up the sound, then
throw in a bunch of calls directly to the PulseAudio library to adjust
the panning.

Moving house this weekend, but I'll try and make a patch if I get some
spare time.

On Sat, Jul 14, 2012 at 9:11 AM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:
> Patches are welcome!
>
> On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:
>>
>>
>>
>> 2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it
<mailto:vitto.giova at yahoo.it>>
>>>
>>> Umh, is there a bug report filed about this?
>>> Vittorio
>>>
>>> On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote:
>>> > I observed this behavior too, really annoying.
>>> >
>>> > On 07/12/2012 01:19 AM, mbentrup wrote:
>>> >> When you build SDL with both GLX and EGL support, the
driver will
>>> >> always use the EGL calls. Currently he only option is to
configure SDL with
>>> >> the --disable-video-opengles switch.
>>
>>
>> It's filed here:
>>
>> http://bugzilla.libsdl.org/show_bug.cgi?id=1428
>>
>>
>> I talked to Sam about this a while ago, we agreed that when
both backends
>> are available, an environment variable should be used to
determine which one
>> to prefer. I haven't had time to work on this yet though.
>>
>> --
>> Gabriel.
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’ve written a patch[1] that implements the environment variable solution,
but I agree that it’s not ideal. The problem is that, at present, the API
doesn’t seem to make any distinction between OpenGL and OpenGL ES at all,
and certainly no distinction between versions of OpenGL ES. (If I’m wrong,
please correct me!)

It’s true that there’s no distinction made between GL and GLES, SDL
just subs the functions from the selected backend in to point to
SDL_GL_CreateContext and friends. There is actually a distinction made
between GLES versions; when setting up the EGL context SDL should grab
(SDL_GL_CONTEXT_MAJOR_VERSION, SDL_GL_CONTEXT_MINOR_VERSION) and pass
them on, so that EGL knows whether you’re going to use GLES 1.1 or
2.0.

The cleanest solution, IMHO, would be to add a new
window flag SDL_WINDOW_OPENGLES to be used instead of SDL_WINDOW_OPENGL.
This is not backwards-compatible, and touches a lot more than just X11.
Other options could be adding an attribute for API version, but that doesn’t
seem as neat.

This sounds more promising, but there’s still a bit of a snag. Namely
the SDL_WINDOW_OPENGLES would be received at window creation time, but
the function pointers are set during SDL init. We could add a second
set of pointers dedicated to GL ES via EGL, which I’m sure would have
some utility outside of X11 (e.g. AMD apparently support it under
Windows, ANGLE for working around crap GL drivers) and shouldn’t break
anything, but it would be a reasonably huge change.On Sun, Jul 15, 2012 at 11:51 PM, David Gow wrote:

As a point of interest, ‘testgles’ works fine with desktop OpenGL (there are
no ES-only calls).

Cheers,

– David

[1] http://bugzilla.libsdl.org/show_bug.cgi?id=1428

On 15/07/12 23:26, Patrick Baggett wrote:

I think this is a really good point. I’d rather fail gently if GL ES 2.0
wasn’t found and my app used that. Crashing seems like a less than graceful
experience.

Patrick

On Sat, Jul 14, 2012 at 12:42 AM, Scott Percival <scott at labyrinthdata.net.au <mailto:scott at labyrinthdata.net.au>> wrote:

I'd disagree that an environment variable would be a good way of doing
it... I understand that's how it's done with the audio backend, but
with GL it's different; your app directly links to the GL/GLES library
for draw calls, so depending how it was built it _needs_ a certain
backend to work properly. By contrast the audio API wraps almost
everything; you don't use the SDL audio APIs to set up the sound, then
throw in a bunch of calls directly to the PulseAudio library to adjust
the panning.

Moving house this weekend, but I'll try and make a patch if I get some
spare time.

On Sat, Jul 14, 2012 at 9:11 AM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:
> Patches are welcome!
>
> On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:
>>
>>
>>
>> 2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it
<mailto:vitto.giova at yahoo.it>>

>>>
>>> Umh, is there a bug report filed about this?
>>> Vittorio
>>>
>>> On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote:
>>> > I observed this behavior too, really annoying.
>>> >
>>> > On 07/12/2012 01:19 AM, mbentrup wrote:
>>> >> When you build SDL with both GLX and EGL support, the
driver will
>>> >> always use the EGL calls. Currently he only option is to
configure SDL with
>>> >> the --disable-video-opengles switch.
>>
>>
>> It's filed here:
>>
>> http://bugzilla.libsdl.org/show_bug.cgi?id=1428
>>
>>
>> I talked to Sam about this a while ago, we agreed that when
both backends
>> are available, an environment variable should be used to
determine which one
>> to prefer. I haven't had time to work on this yet though.
>>
>> --
>> Gabriel.
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Okay, I think I have something for this. Tested it on GL and GLES
machines, it seems to work okay.

  • Add a new SDL GL attribute SDL_GL_CONTEXT_EGL:
    - Only useful for the X11 video driver at the moment
    - Set to 1 for an EGL context, 0 to use the default for the video driver
    - Default is 0, unless library is built for EGL only
    - Should be set after SDL init, but before window/context
    creation (i.e. same place you’d specify attributes for major/minor GL
    version)
  • After a lot of agony pondering the least-terrible way to go about
    it, made it so that X11_GL_LoadLibrary and X11_GLES_LoadLibrary check
    SDL_GL_CONTEXT_EGL. If no GL context exists yet, and the attribute
    choice doesn’t match with the checking function, then it changes all
    the function pointers in the video driver and passes control on to the
    new LoadLibrary method.
  • Likewise, make X11_CreateWindow check this attribute before firing
    off a call to X11_GL_GetVisual/X11_GLES_GetVisual
  • Added a sanity check to the start of X11_GL_LoadLibrary
  • Tidied up SDL_x11opengles.h
  • Moved ownership of the gles_data structure over to
    X11_GLES_LoadLibrary/UnloadLibrary
  • Should incorporate the 3 fixes posted by Andre Heider

This is obviously quite a bit to take in, but is (at least) a proof of
concept for the approach I think EGL/GLX mingling should take. Any
comments/criticism is much appreciated.On Mon, Jul 16, 2012 at 9:13 AM, Scott Percival wrote:

On Sun, Jul 15, 2012 at 11:51 PM, David Gow wrote:

I’ve written a patch[1] that implements the environment variable solution,
but I agree that it’s not ideal. The problem is that, at present, the API
doesn’t seem to make any distinction between OpenGL and OpenGL ES at all,
and certainly no distinction between versions of OpenGL ES. (If I’m wrong,
please correct me!)

It’s true that there’s no distinction made between GL and GLES, SDL
just subs the functions from the selected backend in to point to
SDL_GL_CreateContext and friends. There is actually a distinction made
between GLES versions; when setting up the EGL context SDL should grab
(SDL_GL_CONTEXT_MAJOR_VERSION, SDL_GL_CONTEXT_MINOR_VERSION) and pass
them on, so that EGL knows whether you’re going to use GLES 1.1 or
2.0.

The cleanest solution, IMHO, would be to add a new
window flag SDL_WINDOW_OPENGLES to be used instead of SDL_WINDOW_OPENGL.
This is not backwards-compatible, and touches a lot more than just X11.
Other options could be adding an attribute for API version, but that doesn’t
seem as neat.

This sounds more promising, but there’s still a bit of a snag. Namely
the SDL_WINDOW_OPENGLES would be received at window creation time, but
the function pointers are set during SDL init. We could add a second
set of pointers dedicated to GL ES via EGL, which I’m sure would have
some utility outside of X11 (e.g. AMD apparently support it under
Windows, ANGLE for working around crap GL drivers) and shouldn’t break
anything, but it would be a reasonably huge change.

As a point of interest, ‘testgles’ works fine with desktop OpenGL (there are
no ES-only calls).

Cheers,

– David

[1] http://bugzilla.libsdl.org/show_bug.cgi?id=1428

On 15/07/12 23:26, Patrick Baggett wrote:

I think this is a really good point. I’d rather fail gently if GL ES 2.0
wasn’t found and my app used that. Crashing seems like a less than graceful
experience.

Patrick

On Sat, Jul 14, 2012 at 12:42 AM, Scott Percival <scott at labyrinthdata.net.au <mailto:scott at labyrinthdata.net.au>> wrote:

I'd disagree that an environment variable would be a good way of doing
it... I understand that's how it's done with the audio backend, but
with GL it's different; your app directly links to the GL/GLES library
for draw calls, so depending how it was built it _needs_ a certain
backend to work properly. By contrast the audio API wraps almost
everything; you don't use the SDL audio APIs to set up the sound, then
throw in a bunch of calls directly to the PulseAudio library to adjust
the panning.

Moving house this weekend, but I'll try and make a patch if I get some
spare time.

On Sat, Jul 14, 2012 at 9:11 AM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:
> Patches are welcome!
>
> On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:
>>
>>
>>
>> 2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it
<mailto:vitto.giova at yahoo.it>>

>>>
>>> Umh, is there a bug report filed about this?
>>> Vittorio
>>>
>>> On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote:
>>> > I observed this behavior too, really annoying.
>>> >
>>> > On 07/12/2012 01:19 AM, mbentrup wrote:
>>> >> When you build SDL with both GLX and EGL support, the
driver will
>>> >> always use the EGL calls. Currently he only option is to
configure SDL with
>>> >> the --disable-video-opengles switch.
>>
>>
>> It's filed here:
>>
>> http://bugzilla.libsdl.org/show_bug.cgi?id=1428
>>
>>
>> I talked to Sam about this a while ago, we agreed that when
both backends
>> are available, an environment variable should be used to
determine which one
>> to prefer. I haven't had time to work on this yet though.
>>
>> --
>> Gabriel.
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: gles-fixes.diff
Type: application/octet-stream
Size: 14256 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120718/1d64ddf2/attachment.obj

Hi,

I just subscribed to this list a day ago, so missed this discussion.

You’ve probably seen my patches, which take the envvar solution to fix
the initialization issue.
That’s obviously limited to one API per process runtime, which I
believe is a good first step.

But I think the proper solution needs more than your SDL_GL_CONTEXT_EGL:
If you use OpenGL calls in your application, you specifically want
that API and not OpenGLES.

How about adding 2 new flags to SDL_WindowFlags, something like:

  1. SDL_WINDOW_OPENGL_API_GL
  2. SDL_WINDOW_OPENGL_API_GLES

If none of those is set, it does what SDL currently does: Choose
whatever is available. This is backward compatible and usable for
applications that don’t use GL[ES] calls on their own. The envvar
solution is still handy for this scenario.

The other flags only accept one specific API. But instead of checking
that in the X11 driver, it should be handled in SDL_video.c globally.
That would e.g. prevent getting a GLES context on whatever platforms
if the app specifically asked for GL - and not just a single driver.

Regards,
AndreOn Wed, Jul 18, 2012 at 5:29 PM, Scott Percival wrote:

Okay, I think I have something for this. Tested it on GL and GLES
machines, it seems to work okay.

  • Add a new SDL GL attribute SDL_GL_CONTEXT_EGL:
    - Only useful for the X11 video driver at the moment
    - Set to 1 for an EGL context, 0 to use the default for the video driver
    - Default is 0, unless library is built for EGL only
    - Should be set after SDL init, but before window/context
    creation (i.e. same place you’d specify attributes for major/minor GL
    version)
  • After a lot of agony pondering the least-terrible way to go about
    it, made it so that X11_GL_LoadLibrary and X11_GLES_LoadLibrary check
    SDL_GL_CONTEXT_EGL. If no GL context exists yet, and the attribute
    choice doesn’t match with the checking function, then it changes all
    the function pointers in the video driver and passes control on to the
    new LoadLibrary method.
  • Likewise, make X11_CreateWindow check this attribute before firing
    off a call to X11_GL_GetVisual/X11_GLES_GetVisual
  • Added a sanity check to the start of X11_GL_LoadLibrary
  • Tidied up SDL_x11opengles.h
  • Moved ownership of the gles_data structure over to
    X11_GLES_LoadLibrary/UnloadLibrary
  • Should incorporate the 3 fixes posted by Andre Heider

This is obviously quite a bit to take in, but is (at least) a proof of
concept for the approach I think EGL/GLX mingling should take. Any
comments/criticism is much appreciated.

However the API is shaped, we should keep in mind that we’ll need a way to
do a graceful fallback in some cases, and have a way to check if the app is
using GL or GLES.

So flags like
SDL_WINDOW_OPENGL (if OpenGL is unavailable, fails)
SDL_WINDOW_OPENGL_ES (if GL ES is unavailable, fails)
(SDL_WINDOW_OPENGL_ES | SDL_WINDOW_OPENGL) (allows a fallback to opengl if
GL ES fails)

With this logic, using both the the GL ES and OPENGL flags should be
cross-platform, and easy to check:

SDL_Window* your_window = SDL_CreateWindow( “OpenGL/ES
Test”, SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 800, 600,
SDL_WINDOW_OPENGL| SDL_WINDOW_GLES);

if ( SDL_GetWindowFlags(your_window) & SDL_WINDOW_GLES ) {
// Hurray, we are using OpenGL/ES
} else {
// Do some sort of fallback, create context
}

I have no experience with OpenGL ES or EGL (are they the same?), so I don’t
know how well that would work, but I think it’s best not to add a bunch of
extra API, and just stick with flags. I also don’t see much point of
allowing both OpenGL and OpenGL ES function pointers to be filled (it’s my
understanding that they both do the same essential things, but I could be
wrong).

I could probably hack together some sort of patch but I did see that Andre
has already posted something to that extent. I just recommend only adding
one flag (for OpenGL ES) rather than changing one
(SDL_WINDOW_OPENGL_API_GL) and adding one for OpenGL ES.

Thoughts?
-AlexOn Wed, Jul 18, 2012 at 12:20 PM, Andre Heider <a.heider at gmail.com> wrote:

On Wed, Jul 18, 2012 at 5:29 PM, Scott Percival wrote:

Okay, I think I have something for this. Tested it on GL and GLES
machines, it seems to work okay.

  • Add a new SDL GL attribute SDL_GL_CONTEXT_EGL:
    - Only useful for the X11 video driver at the moment
    - Set to 1 for an EGL context, 0 to use the default for the
    video driver
    - Default is 0, unless library is built for EGL only
    - Should be set after SDL init, but before window/context
    creation (i.e. same place you’d specify attributes for major/minor GL
    version)
  • After a lot of agony pondering the least-terrible way to go about
    it, made it so that X11_GL_LoadLibrary and X11_GLES_LoadLibrary check
    SDL_GL_CONTEXT_EGL. If no GL context exists yet, and the attribute
    choice doesn’t match with the checking function, then it changes all
    the function pointers in the video driver and passes control on to the
    new LoadLibrary method.
  • Likewise, make X11_CreateWindow check this attribute before firing
    off a call to X11_GL_GetVisual/X11_GLES_GetVisual
  • Added a sanity check to the start of X11_GL_LoadLibrary
  • Tidied up SDL_x11opengles.h
  • Moved ownership of the gles_data structure over to
    X11_GLES_LoadLibrary/UnloadLibrary
  • Should incorporate the 3 fixes posted by Andre Heider

This is obviously quite a bit to take in, but is (at least) a proof of
concept for the approach I think EGL/GLX mingling should take. Any
comments/criticism is much appreciated.

Hi,

I just subscribed to this list a day ago, so missed this discussion.

You’ve probably seen my patches, which take the envvar solution to fix
the initialization issue.
That’s obviously limited to one API per process runtime, which I
believe is a good first step.

But I think the proper solution needs more than your SDL_GL_CONTEXT_EGL:
If you use OpenGL calls in your application, you specifically want
that API and not OpenGLES.

How about adding 2 new flags to SDL_WindowFlags, something like:

  1. SDL_WINDOW_OPENGL_API_GL
  2. SDL_WINDOW_OPENGL_API_GLES

If none of those is set, it does what SDL currently does: Choose
whatever is available. This is backward compatible and usable for
applications that don’t use GL[ES] calls on their own. The envvar
solution is still handy for this scenario.

The other flags only accept one specific API. But instead of checking
that in the X11 driver, it should be handled in SDL_video.c globally.
That would e.g. prevent getting a GLES context on whatever platforms
if the app specifically asked for GL - and not just a single driver.

Regards,
Andre


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

However the API is shaped, we should keep in mind that we’ll need a way to
do a graceful fallback in some cases, and have a way to check if the app is
using GL or GLES.

So flags like
SDL_WINDOW_OPENGL (if OpenGL is unavailable, fails)
SDL_WINDOW_OPENGL_ES (if GL ES is unavailable, fails)
(SDL_WINDOW_OPENGL_ES | SDL_WINDOW_OPENGL) (allows a fallback to opengl if
GL ES fails)

With this logic, using both the the GL ES and OPENGL flags should be
cross-platform, and easy to check:

SDL_Window* your_window = SDL_CreateWindow( “OpenGL/ES Test”,
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 800, 600,
SDL_WINDOW_OPENGL| SDL_WINDOW_GLES);

if ( SDL_GetWindowFlags(your_window) & SDL_WINDOW_GLES ) {
// Hurray, we are using OpenGL/ES
} else {
// Do some sort of fallback, create context
}

That sounds good, and is basically my idea without the additional API_GL flag.
The reason I would add that one was because of compatibility. If an
app doesn’t care about the used API (like, it uses only SDL_Texture),
that will break said app because it then needs your GLES flag to be
usable on platforms with only GLES. But if nobody cares… :slight_smile:

I have no experience with OpenGL ES or EGL (are they the same?), so I don’t
know how well that would work, but I think it’s best not to add a bunch of
extra API, and just stick with flags. I also don’t see much point of
allowing both OpenGL and OpenGL ES function pointers to be filled (it’s my
understanding that they both do the same essential things, but I could be
wrong).

One set of GL function pointers is the way to go. It’s not possible to
load 2 different GL implementations at the same time:
readelf -s /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1|grep -w glClear
1317: 0000000000048480 0 FUNC GLOBAL DEFAULT 11 glClear
readelf -s /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so.2|grep -w glClear
142: 0000000000002780 0 FUNC GLOBAL DEFAULT 11 glClear

One set prevents doing stupid things.

Also, this makes swapping the api non trivial, because you need to
make sure that no other windows have a context and no other lib or the
app itself loaded/linked to the api to be swapped.

I could probably hack together some sort of patch but I did see that Andre
has already posted something to that extent. I just recommend only adding
one flag (for OpenGL ES) rather than changing one (SDL_WINDOW_OPENGL_API_GL)
and adding one for OpenGL ES.

Just to be clear: My suggestion was to add the two API flags to the
existing SDL_WINDOW_OPENGL)On Wed, Jul 18, 2012 at 6:45 PM, Alex Barry <alex.barry at gmail.com> wrote:

I went ahead and applied this patch.

One of the advantages of this approach is that the application can
programmatically set whether it wants OpenGL ES or not, which I take
advantage of in the OpenGL ES renderers.

The other advantage is that it can query which one is the default in the
API, which can be useful if an application supports both code paths already
and wants to use whichever one is appropriate for the system.

We may want an environment variable override on top of this, but I figured
it’s a good place to start.

Feedback? Comments? Testing results?

Thanks!On Wed, Jul 18, 2012 at 11:29 AM, Scott Percival <scott at labyrinthdata.net.au wrote:

Okay, I think I have something for this. Tested it on GL and GLES
machines, it seems to work okay.

  • Add a new SDL GL attribute SDL_GL_CONTEXT_EGL:
    - Only useful for the X11 video driver at the moment
    - Set to 1 for an EGL context, 0 to use the default for the video
    driver
    - Default is 0, unless library is built for EGL only
    - Should be set after SDL init, but before window/context
    creation (i.e. same place you’d specify attributes for major/minor GL
    version)
  • After a lot of agony pondering the least-terrible way to go about
    it, made it so that X11_GL_LoadLibrary and X11_GLES_LoadLibrary check
    SDL_GL_CONTEXT_EGL. If no GL context exists yet, and the attribute
    choice doesn’t match with the checking function, then it changes all
    the function pointers in the video driver and passes control on to the
    new LoadLibrary method.
  • Likewise, make X11_CreateWindow check this attribute before firing
    off a call to X11_GL_GetVisual/X11_GLES_GetVisual
  • Added a sanity check to the start of X11_GL_LoadLibrary
  • Tidied up SDL_x11opengles.h
  • Moved ownership of the gles_data structure over to
    X11_GLES_LoadLibrary/UnloadLibrary
  • Should incorporate the 3 fixes posted by Andre Heider

This is obviously quite a bit to take in, but is (at least) a proof of
concept for the approach I think EGL/GLX mingling should take. Any
comments/criticism is much appreciated.

On Mon, Jul 16, 2012 at 9:13 AM, Scott Percival wrote:

On Sun, Jul 15, 2012 at 11:51 PM, David Gow wrote:

I’ve written a patch[1] that implements the environment variable
solution,

but I agree that it’s not ideal. The problem is that, at present, the
API

doesn’t seem to make any distinction between OpenGL and OpenGL ES at
all,

and certainly no distinction between versions of OpenGL ES. (If I’m
wrong,

please correct me!)

It’s true that there’s no distinction made between GL and GLES, SDL
just subs the functions from the selected backend in to point to
SDL_GL_CreateContext and friends. There is actually a distinction made
between GLES versions; when setting up the EGL context SDL should grab
(SDL_GL_CONTEXT_MAJOR_VERSION, SDL_GL_CONTEXT_MINOR_VERSION) and pass
them on, so that EGL knows whether you’re going to use GLES 1.1 or
2.0.

The cleanest solution, IMHO, would be to add a new
window flag SDL_WINDOW_OPENGLES to be used instead of SDL_WINDOW_OPENGL.
This is not backwards-compatible, and touches a lot more than just X11.
Other options could be adding an attribute for API version, but that
doesn’t

seem as neat.

This sounds more promising, but there’s still a bit of a snag. Namely
the SDL_WINDOW_OPENGLES would be received at window creation time, but
the function pointers are set during SDL init. We could add a second
set of pointers dedicated to GL ES via EGL, which I’m sure would have
some utility outside of X11 (e.g. AMD apparently support it under
Windows, ANGLE for working around crap GL drivers) and shouldn’t break
anything, but it would be a reasonably huge change.

As a point of interest, ‘testgles’ works fine with desktop OpenGL
(there are

no ES-only calls).

Cheers,

– David

[1] http://bugzilla.libsdl.org/show_bug.cgi?id=1428

On 15/07/12 23:26, Patrick Baggett wrote:

I think this is a really good point. I’d rather fail gently if GL ES
2.0

wasn’t found and my app used that. Crashing seems like a less than
graceful

experience.

Patrick

On Sat, Jul 14, 2012 at 12:42 AM, Scott Percival <scott at labyrinthdata.net.au <mailto:scott at labyrinthdata.net.au>> wrote:

I'd disagree that an environment variable would be a good way of

doing

it... I understand that's how it's done with the audio backend, but
with GL it's different; your app directly links to the GL/GLES

library

for draw calls, so depending how it was built it _needs_ a certain
backend to work properly. By contrast the audio API wraps almost
everything; you don't use the SDL audio APIs to set up the sound,

then

throw in a bunch of calls directly to the PulseAudio library to

adjust

the panning.

Moving house this weekend, but I'll try and make a patch if I get

some

spare time.

On Sat, Jul 14, 2012 at 9:11 AM, Sam Lantinga <@slouken <mailto:@slouken>> wrote:
> Patches are welcome!
>
> On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:
>>
>>
>>
>> 2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it
<mailto:vitto.giova at yahoo.it>>

>>>
>>> Umh, is there a bug report filed about this?
>>> Vittorio
>>>
>>> On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote:
>>> > I observed this behavior too, really annoying.
>>> >
>>> > On 07/12/2012 01:19 AM, mbentrup wrote:
>>> >> When you build SDL with both GLX and EGL support, the
driver will
>>> >> always use the EGL calls. Currently he only option is to
configure SDL with
>>> >> the --disable-video-opengles switch.
>>
>>
>> It's filed here:
>>
>> http://bugzilla.libsdl.org/show_bug.cgi?id=1428
>>
>>
>> I talked to Sam about this a while ago, we agreed that when
both backends
>> are available, an environment variable should be used to
determine which one
>> to prefer. I haven't had time to work on this yet though.
>>
>> --
>> Gabriel.
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I did think about adding another SDL_WINDOW_OPENGL_ES flag to
compliment SDL_WINDOW_OPENGL. However this only really heaped more
complexity onto the problem; you still only have a single set of
SDL_GL function pointers, so there’d be a lot of weird edge cases to
deal with for setting up contexts, and a lot of code to go back and
change. Also being a bitfield is problematic, as Andre said you can’t
really gracefully fallback to OpenGL ES at runtime (unless you’ve gone
to the huge effort of dynamically loading libGLESv2 and writing a
completely separate rendering codepath), so SDL_WINDOW_OPENGL |
SDL_WINDOW_OPENGL_ES wouldn’t be much help.

With my patch, if you have your SDL library compiled to support both
GLX and EGL (remember that SDL dynamically loads the relevant GL libs
at runtime, so no hard dependency):

  • At window creation, by default it will try to load GLX and fail
    normally if that doesn’t work.
  • If you change SDL_GL_CONTEXT_EGL to 1 beforehand, it will try to
    load EGL and fail normally if that doesn’t work.
  • If you try switching SDL_GL_CONTEXT_EGL while you have an active GL
    session, it’ll be ignored until UnloadLibrary is called to clean the
    session up, after which LoadLibrary will check for it again.

Now that I’ve slept on it, one of the things which I think I might not
have handled optimally is the case where SDL is built for only one
library (GLX or EGL), and SDL_GL_CONTEXT_EGL is changed by the user to
point to the unsupported option. Right now the behaviour is for
LoadLibrary to only bother checking SDL_GL_CONTEXT_EGL if there’s
support for both, otherwise it’ll just plow on ahead creating the
session. I guess it shouldn’t be too hard to tweak this to throw an
error instead.On Thu, Jul 19, 2012 at 6:24 AM, Sam Lantinga wrote:

I went ahead and applied this patch.

One of the advantages of this approach is that the application can
programmatically set whether it wants OpenGL ES or not, which I take
advantage of in the OpenGL ES renderers.

The other advantage is that it can query which one is the default in the
API, which can be useful if an application supports both code paths already
and wants to use whichever one is appropriate for the system.

We may want an environment variable override on top of this, but I figured
it’s a good place to start.

Feedback? Comments? Testing results?

Thanks!

On Wed, Jul 18, 2012 at 11:29 AM, Scott Percival wrote:

Okay, I think I have something for this. Tested it on GL and GLES
machines, it seems to work okay.

  • Add a new SDL GL attribute SDL_GL_CONTEXT_EGL:
    - Only useful for the X11 video driver at the moment
    - Set to 1 for an EGL context, 0 to use the default for the video
    driver
    - Default is 0, unless library is built for EGL only
    - Should be set after SDL init, but before window/context
    creation (i.e. same place you’d specify attributes for major/minor GL
    version)
  • After a lot of agony pondering the least-terrible way to go about
    it, made it so that X11_GL_LoadLibrary and X11_GLES_LoadLibrary check
    SDL_GL_CONTEXT_EGL. If no GL context exists yet, and the attribute
    choice doesn’t match with the checking function, then it changes all
    the function pointers in the video driver and passes control on to the
    new LoadLibrary method.
  • Likewise, make X11_CreateWindow check this attribute before firing
    off a call to X11_GL_GetVisual/X11_GLES_GetVisual
  • Added a sanity check to the start of X11_GL_LoadLibrary
  • Tidied up SDL_x11opengles.h
  • Moved ownership of the gles_data structure over to
    X11_GLES_LoadLibrary/UnloadLibrary
  • Should incorporate the 3 fixes posted by Andre Heider

This is obviously quite a bit to take in, but is (at least) a proof of
concept for the approach I think EGL/GLX mingling should take. Any
comments/criticism is much appreciated.

On Mon, Jul 16, 2012 at 9:13 AM, Scott Percival wrote:

On Sun, Jul 15, 2012 at 11:51 PM, David Gow wrote:

I’ve written a patch[1] that implements the environment variable
solution,
but I agree that it’s not ideal. The problem is that, at present, the
API
doesn’t seem to make any distinction between OpenGL and OpenGL ES at
all,
and certainly no distinction between versions of OpenGL ES. (If I’m
wrong,
please correct me!)

It’s true that there’s no distinction made between GL and GLES, SDL
just subs the functions from the selected backend in to point to
SDL_GL_CreateContext and friends. There is actually a distinction made
between GLES versions; when setting up the EGL context SDL should grab
(SDL_GL_CONTEXT_MAJOR_VERSION, SDL_GL_CONTEXT_MINOR_VERSION) and pass
them on, so that EGL knows whether you’re going to use GLES 1.1 or
2.0.

The cleanest solution, IMHO, would be to add a new
window flag SDL_WINDOW_OPENGLES to be used instead of
SDL_WINDOW_OPENGL.
This is not backwards-compatible, and touches a lot more than just X11.
Other options could be adding an attribute for API version, but that
doesn’t
seem as neat.

This sounds more promising, but there’s still a bit of a snag. Namely
the SDL_WINDOW_OPENGLES would be received at window creation time, but
the function pointers are set during SDL init. We could add a second
set of pointers dedicated to GL ES via EGL, which I’m sure would have
some utility outside of X11 (e.g. AMD apparently support it under
Windows, ANGLE for working around crap GL drivers) and shouldn’t break
anything, but it would be a reasonably huge change.

As a point of interest, ‘testgles’ works fine with desktop OpenGL
(there are
no ES-only calls).

Cheers,

– David

[1] http://bugzilla.libsdl.org/show_bug.cgi?id=1428

On 15/07/12 23:26, Patrick Baggett wrote:

I think this is a really good point. I’d rather fail gently if GL ES
2.0
wasn’t found and my app used that. Crashing seems like a less than
graceful
experience.

Patrick

On Sat, Jul 14, 2012 at 12:42 AM, Scott Percival <scott at labyrinthdata.net.au <mailto:scott at labyrinthdata.net.au>> wrote:

I'd disagree that an environment variable would be a good way of

doing
it… I understand that’s how it’s done with the audio backend,
but
with GL it’s different; your app directly links to the GL/GLES
library
for draw calls, so depending how it was built it needs a certain
backend to work properly. By contrast the audio API wraps almost
everything; you don’t use the SDL audio APIs to set up the sound,
then
throw in a bunch of calls directly to the PulseAudio library to
adjust
the panning.

Moving house this weekend, but I'll try and make a patch if I get

some
spare time.

On Sat, Jul 14, 2012 at 9:11 AM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:
> Patches are welcome!
>
> On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:
>>
>>
>>
>> 2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it
<mailto:vitto.giova at yahoo.it>>

>>>
>>> Umh, is there a bug report filed about this?
>>> Vittorio
>>>
>>> On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote:
>>> > I observed this behavior too, really annoying.
>>> >
>>> > On 07/12/2012 01:19 AM, mbentrup wrote:
>>> >> When you build SDL with both GLX and EGL support, the
driver will
>>> >> always use the EGL calls. Currently he only option is to
configure SDL with
>>> >> the --disable-video-opengles switch.
>>
>>
>> It's filed here:
>>
>> http://bugzilla.libsdl.org/show_bug.cgi?id=1428
>>
>>
>> I talked to Sam about this a while ago, we agreed that when
both backends
>> are available, an environment variable should be used to
determine which one
>> to prefer. I haven't had time to work on this yet though.
>>
>> --
>> Gabriel.
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yeah, feel free to add a patch to handle that case.On Wed, Jul 18, 2012 at 9:49 PM, Scott Percival wrote:

I did think about adding another SDL_WINDOW_OPENGL_ES flag to
compliment SDL_WINDOW_OPENGL. However this only really heaped more
complexity onto the problem; you still only have a single set of
SDL_GL function pointers, so there’d be a lot of weird edge cases to
deal with for setting up contexts, and a lot of code to go back and
change. Also being a bitfield is problematic, as Andre said you can’t
really gracefully fallback to OpenGL ES at runtime (unless you’ve gone
to the huge effort of dynamically loading libGLESv2 and writing a
completely separate rendering codepath), so SDL_WINDOW_OPENGL |
SDL_WINDOW_OPENGL_ES wouldn’t be much help.

With my patch, if you have your SDL library compiled to support both
GLX and EGL (remember that SDL dynamically loads the relevant GL libs
at runtime, so no hard dependency):

  • At window creation, by default it will try to load GLX and fail
    normally if that doesn’t work.
  • If you change SDL_GL_CONTEXT_EGL to 1 beforehand, it will try to
    load EGL and fail normally if that doesn’t work.
  • If you try switching SDL_GL_CONTEXT_EGL while you have an active GL
    session, it’ll be ignored until UnloadLibrary is called to clean the
    session up, after which LoadLibrary will check for it again.

Now that I’ve slept on it, one of the things which I think I might not
have handled optimally is the case where SDL is built for only one
library (GLX or EGL), and SDL_GL_CONTEXT_EGL is changed by the user to
point to the unsupported option. Right now the behaviour is for
LoadLibrary to only bother checking SDL_GL_CONTEXT_EGL if there’s
support for both, otherwise it’ll just plow on ahead creating the
session. I guess it shouldn’t be too hard to tweak this to throw an
error instead.

On Thu, Jul 19, 2012 at 6:24 AM, Sam Lantinga <@slouken> wrote:

I went ahead and applied this patch.

One of the advantages of this approach is that the application can
programmatically set whether it wants OpenGL ES or not, which I take
advantage of in the OpenGL ES renderers.

The other advantage is that it can query which one is the default in the
API, which can be useful if an application supports both code paths
already
and wants to use whichever one is appropriate for the system.

We may want an environment variable override on top of this, but I
figured
it’s a good place to start.

Feedback? Comments? Testing results?

Thanks!

On Wed, Jul 18, 2012 at 11:29 AM, Scott Percival wrote:

Okay, I think I have something for this. Tested it on GL and GLES
machines, it seems to work okay.

  • Add a new SDL GL attribute SDL_GL_CONTEXT_EGL:
    - Only useful for the X11 video driver at the moment
    - Set to 1 for an EGL context, 0 to use the default for the
    video

driver
- Default is 0, unless library is built for EGL only
- Should be set after SDL init, but before window/context
creation (i.e. same place you’d specify attributes for major/minor GL
version)

  • After a lot of agony pondering the least-terrible way to go about
    it, made it so that X11_GL_LoadLibrary and X11_GLES_LoadLibrary check
    SDL_GL_CONTEXT_EGL. If no GL context exists yet, and the attribute
    choice doesn’t match with the checking function, then it changes all
    the function pointers in the video driver and passes control on to the
    new LoadLibrary method.
  • Likewise, make X11_CreateWindow check this attribute before firing
    off a call to X11_GL_GetVisual/X11_GLES_GetVisual
  • Added a sanity check to the start of X11_GL_LoadLibrary
  • Tidied up SDL_x11opengles.h
  • Moved ownership of the gles_data structure over to
    X11_GLES_LoadLibrary/UnloadLibrary
  • Should incorporate the 3 fixes posted by Andre Heider

This is obviously quite a bit to take in, but is (at least) a proof of
concept for the approach I think EGL/GLX mingling should take. Any
comments/criticism is much appreciated.

On Mon, Jul 16, 2012 at 9:13 AM, Scott Percival wrote:

On Sun, Jul 15, 2012 at 11:51 PM, David Gow < david at ingeniumdigital.com> wrote:

I’ve written a patch[1] that implements the environment variable
solution,
but I agree that it’s not ideal. The problem is that, at present, the
API
doesn’t seem to make any distinction between OpenGL and OpenGL ES at
all,
and certainly no distinction between versions of OpenGL ES. (If I’m
wrong,
please correct me!)

It’s true that there’s no distinction made between GL and GLES, SDL
just subs the functions from the selected backend in to point to
SDL_GL_CreateContext and friends. There is actually a distinction made
between GLES versions; when setting up the EGL context SDL should grab
(SDL_GL_CONTEXT_MAJOR_VERSION, SDL_GL_CONTEXT_MINOR_VERSION) and pass
them on, so that EGL knows whether you’re going to use GLES 1.1 or
2.0.

The cleanest solution, IMHO, would be to add a new
window flag SDL_WINDOW_OPENGLES to be used instead of
SDL_WINDOW_OPENGL.
This is not backwards-compatible, and touches a lot more than just
X11.

Other options could be adding an attribute for API version, but that
doesn’t
seem as neat.

This sounds more promising, but there’s still a bit of a snag. Namely
the SDL_WINDOW_OPENGLES would be received at window creation time, but
the function pointers are set during SDL init. We could add a second
set of pointers dedicated to GL ES via EGL, which I’m sure would have
some utility outside of X11 (e.g. AMD apparently support it under
Windows, ANGLE for working around crap GL drivers) and shouldn’t break
anything, but it would be a reasonably huge change.

As a point of interest, ‘testgles’ works fine with desktop OpenGL
(there are
no ES-only calls).

Cheers,

– David

[1] http://bugzilla.libsdl.org/show_bug.cgi?id=1428

On 15/07/12 23:26, Patrick Baggett wrote:

I think this is a really good point. I’d rather fail gently if GL ES
2.0
wasn’t found and my app used that. Crashing seems like a less than
graceful
experience.

Patrick

On Sat, Jul 14, 2012 at 12:42 AM, Scott Percival <scott at labyrinthdata.net.au <mailto:scott at labyrinthdata.net.au>> wrote:

I'd disagree that an environment variable would be a good way of

doing
it… I understand that’s how it’s done with the audio backend,
but
with GL it’s different; your app directly links to the GL/GLES
library
for draw calls, so depending how it was built it needs a
certain

backend to work properly. By contrast the audio API wraps almost
everything; you don't use the SDL audio APIs to set up the

sound,

then
throw in a bunch of calls directly to the PulseAudio library to
adjust
the panning.

Moving house this weekend, but I'll try and make a patch if I

get

some
spare time.

On Sat, Jul 14, 2012 at 9:11 AM, Sam Lantinga < @slouken <mailto:@slouken>> wrote:
> Patches are welcome!
>
> On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:
>>
>>
>>
>> 2012/7/13 Vittorio Giovara <vitto.giova at yahoo.it
<mailto:vitto.giova at yahoo.it>>

>>>
>>> Umh, is there a bug report filed about this?
>>> Vittorio
>>>
>>> On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote:
>>> > I observed this behavior too, really annoying.
>>> >
>>> > On 07/12/2012 01:19 AM, mbentrup wrote:
>>> >> When you build SDL with both GLX and EGL support, the
driver will
>>> >> always use the EGL calls. Currently he only option is to
configure SDL with
>>> >> the --disable-video-opengles switch.
>>
>>
>> It's filed here:
>>
>> http://bugzilla.libsdl.org/show_bug.cgi?id=1428
>>
>>
>> I talked to Sam about this a while ago, we agreed that when
both backends
>> are available, an environment variable should be used to
determine which one
>> to prefer. I haven't had time to work on this yet though.
>>
>> --
>> Gabriel.
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

A quick test yields this on my setup yields:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff727b841 in X11_CreateWindow (_this=0x329f1d0,
window=)
at /home/andre/devel/libsdl/src/video/x11/SDL_x11window.c:397
397 _this->gles_data->eglCreateWindowSurface(_this->gles_data->
(gdb) bt
#0 0x00007ffff727b841 in X11_CreateWindow (_this=0x329f1d0,
window=)
at /home/andre/devel/libsdl/src/video/x11/SDL_x11window.c:397
#1 0x00007ffff7263a3d in SDL_CreateWindow (
title=title at entry=0x7ffff7282a1b “OpenGL test”, x=x at entry=-32,
y=y at entry=-32, w=w at entry=32, h=h at entry=32, flags=flags at entry=10)
at /home/andre/devel/libsdl/src/video/SDL_video.c:1202
#2 0x00007ffff7263874 in ShouldUseTextureFramebuffer ()
at /home/andre/devel/libsdl/src/video/SDL_video.c:174
#3 SDL_VideoInit (driver_name=, driver_name at entry=0x0)
at /home/andre/devel/libsdl/src/video/SDL_video.c:523
#4 0x00007ffff71db737 in SDL_InitSubSystem (flags=flags at entry=33)
at /home/andre/devel/libsdl/src/SDL.c:74
#5 0x00007ffff71db79c in SDL_Init (flags=33)
at /home/andre/devel/libsdl/src/SDL.c:150

Don’t have time right now for hunting that down, but can do later if
nobody beats me.

Regards,
AndreOn Thu, Jul 19, 2012 at 12:24 AM, Sam Lantinga wrote:

I went ahead and applied this patch.

One of the advantages of this approach is that the application can
programmatically set whether it wants OpenGL ES or not, which I take
advantage of in the OpenGL ES renderers.

The other advantage is that it can query which one is the default in the
API, which can be useful if an application supports both code paths already
and wants to use whichever one is appropriate for the system.

We may want an environment variable override on top of this, but I figured
it’s a good place to start.

Feedback? Comments? Testing results?