OpenGL renderer for libSDL2 doesn't actually render

On the Xavier, using the latest JetPack beta:

To get a simple window up, I downloaded and built libSDL2 from

./configure; make; sudo make install worked great!

I then tried a simple video capture program, to capture side-by-side video from my Zed camera. I can capture the video just fine, and it renders fine to the window when I use software mode in SDL2, but the OpenGL and OpenGLES2 renderers don’t work.
The OpenGL renderer just draws black (even if I try to force the texture to be all-blue or whatever.)
The OpenGLES2 renderer crashes. (This may be because the texture is NPOT and maybe there’s a problem in SDL2, but SDL2 is pretty well tested software.)

So, it seems to me that the GL/GLES2 APIs on the Xavier aren’t behaving the way I’d expect them to.

Separately, the libSDL2 configure doesn’t detect Vulkan rendering, and looking on the disk, that’s true – vulkan headers are not included.

Here’s my simple sample program:
As I said, you need to build and install libsdl2 version 2.0.8 to test it, which should be very straightforward given the link above.

Hi snarky,
Does the same application work on r28.2.1/TX2(or TX1)?

I’ve got to dig out my TX2 and see …

Hi snarky,
We simply want to make sure it is regression on r31 or it also does not work on r28. It would be great if you have tried it and can share the test result.

We don’t have experience in running SDL2. Could you share more about its use cases?

SDL2 is one of the most common “get me a window and input devices and perhaps sound” wrapper libraries for games and interactive applications. It’s ported to many platforms, and many shipping games use it as their low-level framework. In that sense, it’s a bit like GLUT, except more aimed towards actually shipping quality. While it started out as a DirectDraw emulation library (a long time ago) these days it lets you choose software, OpenGL, OpenGLES, Vulkan, or various platform-native renderer/driver/backends. I bet your friends over in the game developer support department know about it.

The other nice thing is that it, as a library, builds quite easily. Download, configure, make, no external dependencies!

Anyway, checking this on TX2 is still on my TODO list, but I’ve been slammed with higher priority interrupts, so I will get back here once I actually manage to compare.

Okay, I hooked up the TX2 and built the code on it. After some debugging, it turns out it was me who broke it (of course!)

Specifically, I had moved the video capture to a separate thread, but that also put the SDL_LockTexture() (to update the texture picture) into that other thread, which the SDL library doesn’t like for hardware accelerated renderers.
I had used a proper mutex to avoid re-entering the renderer, but the thread context itself was apparently important. Presumably they didn’t make the underlying GL context active in the other thread, and thus the texture update went nowhere.
The software renderer doesn’t have this problem for whatever reason, which explains the difference.

Thanks for your attention.