The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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 example, resulting in the following errors:



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 (Edit: And yes, it supports OpenGL up to 3.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:


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

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

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

On Fri, Jul 13, 2012 at 5:43 AM, Forest Hale wrote:
_______________________________________________
SDL mailing list

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 wrote:
_______________________________________________
SDL mailing list

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

2012/7/13 Vittorio Giovara


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.

Patches are welcome!

On Fri, Jul 13, 2012 at 9:05 AM, Gabriel Jacobo 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:
_______________________________________________
SDL mailing list

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

SDL 1.2 with OpenGL(R) works fine on Linux.

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 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!) 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=1428

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


_______________________________________________
SDL mailing list

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

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

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.


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.

_______________________________________________
SDL mailing list

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:

_______________________________________________
SDL mailing list

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

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

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

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
}

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

On Wed, Jul 18, 2012 at 12:20 PM, Andre Heider wrote:

On Wed, Jul 18, 2012 at 6:45 PM, Alex Barry wrote:

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


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.


Just to be clear: My suggestion was to add the two API flags to the
existing SDL_WINDOW_OPENGL)
_______________________________________________
SDL mailing list

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

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:

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:
_______________________________________________
SDL mailing list

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:

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

A quick test yields this on my setup yields:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff727b841 in X11_CreateWindow (_this=0x329f1d0,
window=<optimized out>)
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=<optimized out>)
at /home/andre/devel/libsdl/src/video/x11/SDL_x11window.c:397
#1 0x00007ffff7263a3d in SDL_CreateWindow (
title=title@entry=0x7ffff7282a1b "OpenGL test", x=x@entry=-32,
y=y@entry=-32, w=w@entry=32, h=h@entry=32, flags=flags@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=<optimized out>, driver_name@entry=0x0)
at /home/andre/devel/libsdl/src/video/SDL_video.c:523
#4 0x00007ffff71db737 in SDL_InitSubSystem (flags=flags@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,
Andre
_______________________________________________
SDL mailing list

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

Yeah... I think when both our patches were applied, it ended up with
an additional SDL_free(_this->gles_data) somewhere. I'll try and fix
it when I get home from work.

On Thu, Jul 19, 2012 at 2:06 PM, Andre Heider wrote:
_______________________________________________
SDL mailing list

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

Ah, right. It was a case I missed of SDL_VIDEO_OPENGL_ES2 being used
as the authority on which engine to use. I've done a fix (along with
adding in those extra 2 error cases), Andre would you mind running
that same test case again with this patch to see if it gets caught?

On Thu, Jul 19, 2012 at 2:51 PM, Scott Percival
wrote:

_______________________________________________
SDL mailing list

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

On Thu, Jul 19, 2012 at 1:34 PM, Scott Percival
wrote:

Another quick test, and it works here without SEGV now.
GL/ES1/ES2 was compiled in, I get GL per default, and with
SDL_GL_SetAttribute(SDL_GL_CONTEXT_EGL, 1) I get ES.

SDL_GL_GetAttribute(SDL_GL_CONTEXT_EGL, &value) also reports the correct value.

Regards,
Andre
_______________________________________________
SDL mailing list

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

Patch applied!

On Thu, Jul 19, 2012 at 7:34 AM, Scott Percival wrote: