RenderTarget texture got deleted between RenderPresent

[ChliHug]

I’m not sure there is anything Raspberry Pi specific to all the other SDL libraries, the packages from the repositories should be just fine.

As for SDL2 itself, check what video drivers you now have with SDL_GetNumVideoDrivers and SDL_GetVideoDriver. If one of them is rpi, then you have support for the firmware-side Raspberry Pi driver.

If you get that error message when you initialized SDL with the rpi driver, it may be related to the issue that the default OpenGL attributes will default to OpenGL 2.1. You can workaround this by disabling OpenGL when building SDL or setting the OpenGL attributes of your application to one of the OpenGL ES versions with (see SDL_GL_SetAttribute). This also has just been fixed in the latest development version of SDL. Have a look at this site on how to get the latest source code. The latest version also has a new KMSDRM video driver which, if enabled, will work with the new vc4 driver for the Raspberry Pi.

[Bluescreen]

I now uninstalled mesa-common-dev because I found that at several places in the web. But it does not help. Then I added a list of the videodrivers, as suggested by ChliHug.

This is my initialization code:

    // start SDL video
    if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO)<0)
    {
            printlog(LOG_ERROR,"Cannot initialize SDL: %s",SDL_GetError());
            return 1;
    }
    atexit(GUI_quit); // remember to quit SDL
    
    for (i=0; i<SDL_GetNumVideoDrivers();i++)
            printlog(LOG_DEBUG,"Videodriver found: %s",SDL_GetVideoDriver(i));
    
    if (flags != Mix_Init(flags))
    {
            printlog(LOG_ERROR, "Cannot initialize SDL_Mixer: %s", SDL_GetError());
            return 1;
    }
    
    // open the screen window
    window = SDL_CreateWindow("YaPS", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 1024, 768, SDL_WINDOW_SHOWN);
    if (!window)
    {
            printlog(LOG_ERROR, "Could not create Window: %s",SDL_GetError());
            return 1;
    }
    
    renderer = SDL_CreateRenderer(window, 0, SDL_RENDERER_ACCELERATED | SDL_RENDERER_TARGETTEXTURE);
    if (!renderer)
    {
            printlog(LOG_ERROR, "Could not create Renderer: %s",SDL_GetError());
            return 1;
    }

And this is my output (I run my application as root to avoid user rights problems with the framebuffer):

G1 Full KMS:

05.09.2017,17:42:01: ERROR  : Cannot initialize SDL:

G2 Fake KMS:
G3 None:

05.09.2017,17:46:16: DEBUG  : Videodriver found: RPI
05.09.2017,17:46:16: DEBUG  : Videodriver found: dummy
05.09.2017,17:46:16: ERROR  : Could not create Window: Could not initialize OpenGL / GLES library

As you can see. If I activate Full KMS it could not initialize at all. The other cases initialize SDL and see the RPI driver but fail to create the window.

I built SDL2 with the following config:

../configure --host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl

So there should be no false opengl because of --disable-video-opengl

I have to check the latest development sources now as suggested by ChliHug. But why? Everything was fine on my old Raspian.

[Bluescreen]

Now I have compiled the latest Mercurial snapshot of SDL2. But there is no change at all. All video modes/drivers are as described above.

So I had a little renderer problem at first and now have a complete failure. The only thing I can think of now is to reinstall the raspi with the full featured version of Raspian (not the light version) and hope that it works then.

Or not use SDL or other bloated libraries and draw directly on the framebuffer. My GUI application (not a game) does not need all that high sophisticated stuff of SDL. I only need some nice text rendering, some blitting of images (png and jpg) and non-waiting keyboard entry. Maybe at a later stage video playing, but I think that’s beyond my abilities anyway.

Any more ideas.

[ChliHug]

The SDL KMSDRM driver is disabled by default right now. Enable it with --enable-video-kmsdrm on the configure line. It also requires libgbm. Should be available with the libgbm-dev package.

You either need to select the “Fake KMS” or “Full KMS” option if you want to use it. This will disable the old driver and the SDL RPI driver doesn’t work anymore. Not a problem if the KMSDRM driver works, of course.

So there should be no false opengl because of --disable-video-opengl

Yeah, that’s odd. I was certain that would work.

But why? Everything was fine on my old Raspian.

I’m guessing you had a special package and not the one from the Debian repository.

I’ll check again why it could throw that message there.

Edit: Oh, and check what driver actually got initialized with SDL_GetCurrentVideoDriver. Just to make sure.

Edit2: Arblgarg! They changed the file names. Known since July 2016, someone mentioned SDL will break, no bug report in the SDL bug tracker. Absolutely terrific.

At least we have environment variables to work around it. Set SDL_VIDEO_GL_DRIVER=/opt/vc/lib/libbrcmGLESv2.so and SDL_VIDEO_EGL_DRIVER=/opt/vc/lib/libbrcmEGL.so before you start your application if you want to use the RPI driver.

[Bluescreen]

With the option --enable-video-kmsdrm I cannot compile the SDL sources I get the following error:

In file included from /home/pi/SDL-2.0.6-11426/src/video/raspberry/SDL_rpievents.c:29:0:
/home/pi/SDL-2.0.6-11426/src/video/raspberry/SDL_rpivideo.h:47:5: error: unknown type name 'EGL_DISPMANX_WINDOW_'
 EGL_DISPMANX_WINDOW_T dispman_window;
 ^~~~~~~~~~~~~~~~~~~~~

I set the mentioned environment variables, but that doesn’t change anything. I cannot output the SDL_GetCurrentVideoDriver when using KSM because SDL does not initialize at all. It just stops with an empty error string as mentioned above.

If I use fake_KSM I get this output:

07.09.2017,19:11:44: DEBUG  : Videodriver found: RPI
07.09.2017,19:11:44: DEBUG  : Videodriver found: dummy
07.09.2017,19:11:44: DEBUG  : Using display driver 'RPI'.
07.09.2017,19:11:44: ERROR  : Could not create Window: Could not initialize OpenGL / GLES library

Since SDL2 seems to be broken, I have either revert to my old setting, living with the texture bug and never ever update Linux. Or I have to skip SDL and draw directly on the framebuffer. Or maybe use SDL1. Maybe the last would be the best solution.

[ChliHug]

The files do exist, right?

I’ll check if this is an issue with the lite version and write down all the steps.

[Bluescreen]

You mean the SDL_rpi… include files? Yes they exist. Maybe there is some EGL stuff missing on the light version.

[Bluescreen]

Hm, SDL_rpivideo.h includes some files I do not find:

#include “bcm_host.h”
#include “GLES/gl.h”
#include “EGL/egl.h”
#include “EGL/eglext.h”

Were should they be?
Edit: ok, found them in the chronos subdir. I searched the whole src folder of SDL for that EGL_DISPMAN string and I found it exactly at one place: in that mentiones include file. Nowwhere else.

[ChliHug]

chronos? They should be in /opt/vc/include. At least they are on my Raspbian Stretch.

I put Raspbian Stretch Lite on an SD card and executed these commands. Got me a working SDL2 with the RPI and KMSDRM driver.

sed 's/^#deb-src/deb-src/' /etc/apt/sources.list | sudo dd of=/etc/apt/sources.list   # Activate sources
sudo apt-get update                      # Update package list
sudo apt-get upgrade                     # Upgrade installed packages
sudo apt-get install mercurial           # Install mercurial
sudo apt-get build-dep libsdl2           # Install most build dependencies
sudo apt-get install libgbm-dev          # Install the libgbm dependency
sudo apt-get install libgl1-mesa-dri     # Install the vc4 driver
hg clone https://hg.libsdl.org/SDL       # Get the source with mercurial
mkdir SDL/out                            # Create build directory
cd SDL/out
../configure --disable-video-x11 --disable-video-wayland --enable-video-kmsdrm --host arm-raspberry-linux-gnueabihf --disable-rpath 
make -j4
sudo make install                        # Install into /usr/local
sudo ldconfig                            # Update ld cache to make the linker aware of the new library

The firmwire-side driver should work with this immediately.

Change over to the KMS driver with raspi-config to test the KMSDRM driver. Because the RPI and KMSDRM driver bite each other a bit, you have to start your application with more environment variables:

SDL_VIDEODRIVER=kmsdrm SDL_VIDEO_GL_DRIVER=libGL.so.1 SDL_VIDEO_EGL_DRIVER=libEGL.so ./application

This isn’t necessary if you just don’t build it with the RPI driver.

[Jacob_Lifshay]

The first command you have does nothing. I would use

sudo sed -i 's/^#deb-src/deb-src/' /etc/apt/sources.list

[Bluescreen]

I just tried it on my actual installation. I am getting a bit further. When I start my application I got SDL initialized with the KRM driver, but cannot open a SDL window. On the console I get three times the message

MESA-LOADER: failed to retrieve device information

And in my logfile I get

08.09.2017,05:17:59: DEBUG  : SDL version 2.0.6 found
08.09.2017,05:17:59: DEBUG  : Videodriver found: RPI
08.09.2017,05:17:59: DEBUG  : Videodriver found: KMSDRM
08.09.2017,05:17:59: DEBUG  : Videodriver found: dummy
08.09.2017,05:17:59: DEBUG  : Using display driver 'KMSDRM'.
08.09.2017,05:17:59: ERROR  : Could not create Window: Could not load EGL library

I think I will reinstall Raspian. Maybe I cracked somethink with my many tries.

[Bluescreen]

Ok, after a fresh install I get SDL up and see some of my GUI elements. But now I have several other issues which I have not on my Ubuntu PC.

1. “Mixer Build without MP3 support”, I had that once, but cannot remember what I did against it.
2. The SDL image library seems to not support JPGs, on the PC it does.
3. I don’t see my cached textures (much like my initial problem)
4. My program crashes at some point with a segmentation fault. May have something with error 1 or 2

What is also strange: I get two messages about the used video driver in my log:

08.09.2017,10:11:22: DEBUG : Using display driver ‘KMSDRM’.
08.09.2017,10:11:22: DEBUG : Using display driver ‘opengl’.

The first is directlectly after SDL_init using SDL_GetCurrentVideoDriver().
The second is after opening the SDL windows and the renderer using info.name from SDL_GetRendererInfo(renderer, &info)

Why they are different?

[Bluescreen]

Now I solved three of the errors:

1. I had to configure sdl2_mixer with --enable-music-mp3-smpeg and maybe smpeg needed ffmpeg.
2. I had to install libjpeg9 and NOT libtiff. libtiff deinstalls libjpeg and uses another jpeg library which fail to load at least my jpgs.
3. No idea yet, this is nearly the problem for which I opened this thread.
4. Had to do with 2. Because no jpeg support my bachgound image load failed, but later I free’d it. And freeing a null-pointer is not a godd idea.

But now I recognized a new very bad problem. The keypresses at the console keyboard arrive in my SDL up but they also arrived at the console prompt. When I close my programm all my keypresses are seen on the underlying console.

[ChliHug]

The first is directlectly after SDL_init using SDL_GetCurrentVideoDriver().

The second is after opening the SDL windows and the renderer using info.name from SDL_GetRendererInfo(renderer, &info)

Why they are different?

The first is a SDL video driver. This is what interface SDL uses for that platform or operating system to get video stuff up and running.

The second is a SDL render driver. These are backed by graphics APIs (like the OpenGL and Direct3D variants) provided by the platform or operating system. Every platform is a bit different on how to get to these APIs and that’s what the video driver takes care of. The exception is the software renderer which comes with SDL.

I don’t see my cached textures (much like my initial problem)

Can you provide a simple, complete test case that shows this problem? We can then investigate in detail. It really should not disappear on you like that.

But now I recognized a new very bad problem. The keypresses at the console keyboard arrive in my SDL up but they also arrived at the console prompt. When I close my programm all my keypresses are seen on the underlying console.

Yes, this is a known issue. It’s apparently really tricky to capture the terminal input. SDL has something in place that locks the terminal, but only for an actual non-remote console. And if SDL doesn’t get properly shut down, all input will be locked.

As a workaround, you can do something like this:

script -q -c "/usr/bin/sdl2application" /dev/null

Input does not get suppressed, but the shell won’t interpret the key presses as commands.

However, if you’re starting the application remotely… Hm, not sure. I have to think about that.

[Bluescreen]

I fear, I can build a test case only in two weeks, because I go on holiday tomorrow and don’t want to take Raspberry, monitor, PC and all the stuff with me. I think my girlfriend would not like that.

That keyboard capture issue does not happen on old installation with SDL 2.0.4 and Wheezy.
If I start my application locally I cannot use the console anymore if I terminate it. As you said, the input seems stuck.

The “test case” is in the first post, but not as a complete program. It is an excerpt of my whole application. But you can see what I am trying. At the first pause the screen is black (with the old SDL I see a black screen with a blue box). At the second pause the screen is black again, in both versions of SDL. After the second pause my application starts and draws all the nice things it should, only not my precreated textures.

Very much thanks for support this far. I will come back to this issue in two weeks.

Thorsten

[ChliHug]

But you can see what I am trying.

I tried it and it worked for me, that’s why I’m asking for more.

Hope you have a relaxing holiday.

[Bluescreen]

Hi again,

I just created a test program for this. You can download it from http://www.trektech.de/test/sdltest.c

It seems that the first SDL_RenderPresent does nothing. The following work as intended. But the offscreen texture seems to be a transparent texture, despite what I drawed onto it. If the blendmode is set to SDL_BLENDMODE_BLEND did not see the texture at all, otherwise you see a black rectangle instead of the blue.

I thought, maybe I have to do a RenderPresent also to the offscreen texture, but that does draw the blue rectangle directly to the screen, not onto the texture.

For me it seems the renderer cannot draw onto a target texture, despite it’s flags that indicate it can.

When I see all that overhead using GPU acceleration (draw onto a surface, convert surface to texture, transfer texture to GPU and draw it to screen), I wonder if it is effective at all for such simple things like a 2D GUI.

Maybe it is more effective to draw everything in the SDL1 manner to one surface and then “copy” it to the screen. But this copying is also slow (convert it to texture, draw to screen by GPU). Maybe I should use SDL1 or direct framebuffer access and skip all that SDL2 stuff. But I read about the framebuffer is very slow on the Raspberry. The only backdraw I see is, if I later want to show full HD video with overlaid GUI elements. There I surely need the GPU.

But maybe you know a more efficient way to draw a 2D GUI. What I want is a background image and onto it some semitransparent GUI buttons and scrollable picture lists (album covers or something like that.)

[ChliHug]

SDL_SetRenderTarget only works with textures created with SDL_TEXTUREACCESS_TARGET. It will throw an error at you if you try with anything else.

I’m sorry I didn’t ask more specifically about that streaming texture comment in your first post. It confused me because it didn’t reflect your code sample, which was correct.

Also for the first SDL_RenderPresent going wrong. Try a loop with SDL_PumpEvents instead of SDL_Delay.

Edit: I just saw you’re always using the first renderer by passing 0 as the second argument to SDL_CreateRenderer. For me, that was opengl which is not supported by the RPI driver. You might want to use -1 for an automatic selection or search for a specific one by name with SDL_GetNumRenderDrivers and SDL_GetRenderDriverInfo.

[Bluescreen]

SDL_SetRenderTarget only works with textures created with SDL_TEXTUREACCESS_TARGET. It will throw an error at you if you try with anything else.

Ok, that works on the demo, but not in my application. But it shows that it is working. I thought I tried that already. So I have to investigate what else did I wrong.

Also for the first SDL_RenderPresent going wrong. Try a loop with SDL_PumpEvents instead of SDL_Delay.

What should the delay have to do with the rendering. I had no delay at all first. I made it only because I thought, maybe the renderer needs some time.

I don’t think it has to do with the second parameter 0 at CreateRenderer. But I tested -1 and there is no difference. I also read that you shouldn’t give the flag SDL_RENDERER_ACCELERATED when using the GL driver. I tried that too, with no difference.

[ChliHug]

What should the delay have to do with the rendering. I had no delay at all first. I made it only because I thought, maybe the renderer needs some time.

Technically, it shouldn’t. I tried your code on Windows with Direct3D and the delay somehow broke the renderer. Didn’t investigate further what went wrong. I also experienced a similar issue with the KWin window manager of the KDE project where the window didn’t show up fast enough and the first update of the window content was dropped. Now I’m always very suspicious of the first update right after window and renderer creation.

I also read that you shouldn’t give the flag SDL_RENDERER_ACCELERATED when using the GL driver.

There’s no effect if you leave it out or not. The opengl renderer is always flagged as accelerated and the flag doesn’t have an effect on context creation. Unless an older version of SDL2 had something weird going on I don’t know about…