CODEWITHSUNDEEP
c++linuxsdl
Callum.W
Callum.W

Reputation: 17

SDL2 hardware accelerated renderer crashes linux when using Proprietary drivers on xubuntu 12.04?

I am creating a small 2D game library (That's right world, another one!) in C++ using SDL and I finally got around to testing its current state (very much a work in progress) on linux(xubuntu 12.04). Up until now I have mostly been working on my Windows 10 install. Note: My linux and windows 10 installs are on the same machine.

At first I was using the xorg nvidia driver, my code was using hardware accelerated rendering (i.e. using the SDL_RENDERER_ACCELERATED flag when creating the SDL_Renderer) but when I ran my code I was getting poor frame rate ~100FPS, bear in mind that at this point I am only testing it by drawing one little animation on screen and on windows I was getting ~1200FPS.

I had the idea that it may be because of the graphics driver. So I switched to the recommended nvidia proprietary driver for my GPU, restarted, recompiled, and ran my game again. Then an empty window appeared, my computer froze but the FPS counter in the window title reported ~15000 FPS (woohoo!). I sighed, began bashing on my keyboard, ctrl-alt-del logged me out, and I logged back into the same frozen screen as before.

After a hard-restart I examined my test program's log and it reported that it successfully entered the game loop i.e. began rendering frames.

Now, if I add a delay in the main loop or use vsync everything is fine (and faster when using the proprietary nvidia driver), no crashes. Everything as defined.

I am confused as to what is happening, I know that my program is trying to go as fast as it can if I don't have a sleep in there but I wouldn't have thought the scheduler would give it so much processor time as to neglect the rest of the system. I tried looking into the differences between the Windows and linux schedulers but I can find a solid reason as to why my program would runaway on linux.

You can view the library code here: https://github.com/callumW/Howler the library is in Howler/ and the test program is in testsrc/ the main loop being in Game.cpp: run().

(As a side note, if you have any suggestions to the library code I would be glad to receive them).

Does anyone have any ideas as to what is happening?

It is evident that I need to cap the frame rate, and seeing as I'm not short of FPS that is not an issue. I also assume this is good practice as to not use power unnecessarily. But this peaked my interest and I wondered if anyone had an answer for me.

Upvotes: 0

Views: 1209

Answers (2)

Wutipong Wongsakuldej
Wutipong Wongsakuldej

Reputation: 499

I'd add SDL_Delay() inside the main loop. Something like :-

while(running) {
    while(SDL_PollEvent(&e) != 0) {
        if(e.type == SDL_KEYDOWN) {
            if(e.key.keysym.sym == SDLK_ESCAPE) {
                running = false;
                break;
            }
        }
        else if(e.type == SDL_QUIT) {
            running = false;
            break;
        }
    }
    update();
    frames++;
    //Add a delay here
    SDL_Delay(0);
}

This is to give the cpu time back to the OS. In some OS (like older Windows if I'm not mistaken) if you infinitely spin loop, your application will freeze, the OS would think your application is unresponsive and will try to kill it. Etc.

I'm not really sure if this is your case, give it a try. You might want to change the value of the parameter (essentially it's the length of time you want to delay, though it's not guaranteed to be exact). I usually use 0 or 1 in the case that I don't want to limit the framerate. 13 will cap your framerate at around 60fps.

Upvotes: 0

keltar
keltar

Reputation: 18409

Hint for the future - there is no need to reboot. Enable X kill sequence (usually ctrl-alt-backspace, but disabled by default in modern distros, you have to enable it manually) as last resort, but usually it is just ctrl-alt-f1, login to tty, kill offending process, then return back to X with ctrl-alt-fN (the number of tty where X sits, most often 7). If you're working with graphics you probably will need that sooner or later.

Not sure if your problem was exactly the same as I've seen when running your program, but it is very likely so. You display FPS in window title, sending it to window manager on each frame, 15 thousands times per second. Window manager gets confused by so many window title updates (at least openbox does. Haven't tested with different WMs). Not sure if it will eventually flush accumulated changes or just hang forever; didn't wait.

Basically don't update window title more often than 10 times per second.

Upvotes: 1

Related Questions