I’m using SDL2 in my Ubuntu development environment, and I’ve run into a situation where using the software renderer outperforms the hardware accelerated renderer. This only occurs on my Ubuntu environment, in Windows everything performs as expected, with hardware acceleration massively outperforming the software fallback.
I create 10,000 “boxes” with the same 20x20 texture, and move them each frame (as a performance test). With hardware rendering I get 19 FPS, software gets 66 FPS or so.
The loop is really simple:
Code:
while (running){
SDL_RenderClear(ren);
//loop the array of boxes
for (i = 0; i < 10000; i++) {
//this just calls SDL_RenderCopy() for the box
renderSprite(tex, ren, boxes[i].x, boxes[i].y);
boxes[i].x += boxes[i].velocity * boxes[i].direction;
boxes[i].y += boxes[i].velocity * boxes[i].direction;
}
SDL_RenderPresent(ren);
}
Linux machine: 2.4GHz Core 2 Duo, Radeon HD 3670
Windows machine: 2.3 GHz Core 2 Duo, Nvidia 9800 GTX+
Linux Hardware rendering: 19 FPS
Linux Software rendering: 66 FPS
Windows Hardware rendering: 97 FPS
Windows Software rendering: 48 FPS
I also get similar results (on my 5 year old net book, though), which has no drivers for the graphics card. Windows works as expected, yet under Ubuntu software outperforms OpenGL. I thought that was due to the lack of drivers, but your post put me into thinking.On 13 ??? 2013, at 9:38 ?.?., “pyrrish” wrote:
I’m using SDL2 in my Ubuntu development environment, and I’ve run into a situation where using the software renderer outperforms the hardware accelerated renderer. This only occurs on my Ubuntu environment, in Windows everything performs as expected, with hardware acceleration massively outperforming the software fallback.
I create 10,000 “boxes” with the same 20x20 texture, and move them each frame (as a performance test). With hardware rendering I get 19 FPS, software gets 66 FPS or so.
The loop is really simple:
Code:
while (running){
SDL_RenderClear(ren);
//loop the array of boxes
for (i = 0; i < 10000; i++) {
//this just calls SDL_RenderCopy() for the box
renderSprite(tex, ren, boxes[i].x, boxes[i].y);
boxes[i].x += boxes[i].velocity * boxes[i].direction;
boxes[i].y += boxes[i].velocity * boxes[i].direction;
}
SDL_RenderPresent(ren);
}
Linux machine: 2.4GHz Core 2 Duo, Radeon HD 3670
Windows machine: 2.3 GHz Core 2 Duo, Nvidia 9800 GTX+
Linux Hardware rendering: 19 FPS
Linux Software rendering: 66 FPS
Windows Hardware rendering: 97 FPS
Windows Software rendering: 48 FPS
It could still be an issue with the drivers though, I wouldn’t be
surprised if OpenGL is being software rendered there. Are you sure the
proper OpenGL drivers are actually working?
Probably an easy way would be to test a 3D game and see how it performs.
2013/10/13, neoaggelos at gmail.com :> I also get similar results (on my 5 year old net book, though), which has no
drivers for the graphics card. Windows works as expected, yet under Ubuntu
software outperforms OpenGL. I thought that was due to the lack of drivers,
but your post put me into thinking.
On 13 ??? 2013, at 9:38 ?.?., “pyrrish” wrote:
I’m using SDL2 in my Ubuntu development environment, and I’ve run into a
situation where using the software renderer outperforms the hardware
accelerated renderer. This only occurs on my Ubuntu environment, in
Windows everything performs as expected, with hardware acceleration
massively outperforming the software fallback.
I create 10,000 “boxes” with the same 20x20 texture, and move them each
frame (as a performance test). With hardware rendering I get 19 FPS,
software gets 66 FPS or so.
The loop is really simple:
Code:
while (running){
SDL_RenderClear(ren);
//loop the array of boxes
for (i = 0; i < 10000; i++) {
//this just calls SDL_RenderCopy() for the box
renderSprite(tex, ren, boxes[i].x, boxes[i].y);
boxes[i].x += boxes[i].velocity * boxes[i].direction;
boxes[i].y += boxes[i].velocity * boxes[i].direction;
}
SDL_RenderPresent(ren);
}
Linux machine: 2.4GHz Core 2 Duo, Radeon HD 3670
Windows machine: 2.3 GHz Core 2 Duo, Nvidia 9800 GTX+
Linux Hardware rendering: 19 FPS
Linux Software rendering: 66 FPS
Windows Hardware rendering: 97 FPS
Windows Software rendering: 48 FPS
Something to do with unity’s compositing?On Oct 13, 2013 3:49 PM, “pyrrish” wrote:
**
According to glxinfo, it’s not reverting to software:
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on AMD RV635
I loaded up an old copy of Darwinia and it runs as expected, no major
issues.
Sik wrote:
It could still be an issue with the drivers though, I wouldn’t be
surprised if OpenGL is being software rendered there. Are you sure the
proper OpenGL drivers are actually working?
Probably an easy way would be to test a 3D game and see how it performs.
I tried disabling Unity and reverting to Gnome - unfortunately the issue persists. I’m going to try building this on a fresh Linux Mint partition on the same machine - I’ll report back.
Andre D wrote:> Something to do with unity’s compositing?
I’m not sure about that, but when using Mesa OpenGL ES, EGL complains for no hardware acceleration. I dont’t have the time right now, but when I come back I’m gonna run glxinfo to check out.
As for 3D games, I don’t think that’s gonna work – it’s an Asus Eee Pc 1101ha with Intel atom 1.3 GHZ and intel gma 500 (haven’t found any drivers for Linux systems). Even YouTube videos cause lag. I still don’t know why I haven’t throw it off yet.On 13 ??? 2013, at 10:02 ?.?., Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
It could still be an issue with the drivers though, I wouldn’t be
surprised if OpenGL is being software rendered there. Are you sure the
proper OpenGL drivers are actually working?
Probably an easy way would be to test a 3D game and see how it performs.
I also get similar results (on my 5 year old net book, though), which has no
drivers for the graphics card. Windows works as expected, yet under Ubuntu
software outperforms OpenGL. I thought that was due to the lack of drivers,
but your post put me into thinking.
On 13 ??? 2013, at 9:38 ?.?., “pyrrish” wrote:
I’m using SDL2 in my Ubuntu development environment, and I’ve run into a
situation where using the software renderer outperforms the hardware
accelerated renderer. This only occurs on my Ubuntu environment, in
Windows everything performs as expected, with hardware acceleration
massively outperforming the software fallback.
I create 10,000 “boxes” with the same 20x20 texture, and move them each
frame (as a performance test). With hardware rendering I get 19 FPS,
software gets 66 FPS or so.
The loop is really simple:
Code:
while (running){
SDL_RenderClear(ren);
//loop the array of boxes
for (i = 0; i < 10000; i++) {
//this just calls SDL_RenderCopy() for the box
renderSprite(tex, ren, boxes[i].x, boxes[i].y);
boxes[i].x += boxes[i].velocity * boxes[i].direction;
boxes[i].y += boxes[i].velocity * boxes[i].direction;
}
SDL_RenderPresent(ren);
}
Linux machine: 2.4GHz Core 2 Duo, Radeon HD 3670
Windows machine: 2.3 GHz Core 2 Duo, Nvidia 9800 GTX+
Linux Hardware rendering: 19 FPS
Linux Software rendering: 66 FPS
Windows Hardware rendering: 97 FPS
Windows Software rendering: 48 FPS
I’m using SDL2 in my Ubuntu development environment, and I’ve run into a situation where using the software renderer outperforms the hardware accelerated renderer. This only occurs on my Ubuntu environment, in Windows everything performs as expected, with hardware acceleration massively outperforming the software fallback.
I create 10,000 “boxes” with the same 20x20 texture, and move them each frame (as a performance test). With hardware rendering I get 19 FPS, software gets 66 FPS or so.
Linux machine: 2.4GHz Core 2 Duo, Radeon HD 3670
Windows machine: 2.3 GHz Core 2 Duo, Nvidia 9800 GTX+
Linux Hardware rendering: 19 FPS
Linux Software rendering: 66 FPS
Windows Hardware rendering: 97 FPS
Windows Software rendering: 48 FPS
Are you using the Catalyst drivers, or the generic “radeon” driver?
I’ve run into a rather weird situation on my system (with an older Radeon card using the generic drivers), and I traced it down to SDL_RenderClear() taking a ridiculous amount of time.
My workaround for this was to replace the calls to SDL_RenderClear() with a call to SDL_RenderFillRect(), which speeded things up enormously. So try that and see if it makes any performance difference.
Are you using the Catalyst drivers, or the generic “radeon” driver?
I’ve run into a rather weird situation on my system (with an older Radeon card using the generic drivers), and I traced it down to SDL_RenderClear() taking a ridiculous amount of time.
My workaround for this was to replace the calls to SDL_RenderClear() with a call to SDL_RenderFillRect(), which speeded things up enormously. So try that and see if it makes any performance difference.
Okay, replying to myself. At least I’m not arguing with myself…yet
Compiled and ran your code on my system, and I’m seeing the same issues - with the 10,000 boxes, performance is much worse with a hardware accelerated renderer than with the software renderer. My RenderClear() suggestion produced no results ( I was only seeing that one when rendering to a texture anyway).
But the difference gradually switches to the other way around as you reduce the number of boxes being drawn between SDL_RenderPresents(). It looks like there’s an O(n^2) type issue involved here - the more RenderCopy()'s you do before the RenderPresent(), the worse the hardware rendering performance gets…
If you’re using the “radeon” driver, you might try switching to the Catalyst drivers and see if that helps.
That probably isn’t a good metric, YouTube is choked up with
javascript like crazy and it’s impossible to use the player without
it… (for reference: on my system YouTube always lags even with 360p
videos, yet the media player can do 720p at full framerate just fine)
Thanks for the suggestion, and for trying out the code. I am using the generic drivers here. The reason is because fglrx (the AMD Catalyst drivers for Linux) no longer support the Radeon HD 2k - 4k series (mine is a 3k series). They still have legacy drivers available, but they don’t work with more recent versions of Xorg on the newer distro releases. It is possible to downgrade Xorg to force compatibility with the legacy drivers. I think I’ll have to try this.
lloyd_b wrote:>
Okay, replying to myself. At least I’m not arguing with myself…yet
Compiled and ran your code on my system, and I’m seeing the same issues - with the 10,000 boxes, performance is much worse with a hardware accelerated renderer than with the software renderer. My RenderClear() suggestion produced no results ( I was only seeing that one when rendering to a texture anyway).
But the difference gradually switches to the other way around as you reduce the number of boxes being drawn between SDL_RenderPresents(). It looks like there’s an O(n^2) type issue involved here - the more RenderCopy()'s you do before the RenderPresent(), the worse the hardware rendering performance gets…
If you’re using the “radeon” driver, you might try switching to the Catalyst drivers and see if that helps.
That probably isn’t a good metric, YouTube is choked up with
javascript like crazy and it’s impossible to use the player without
it… (for reference: on my system YouTube always lags even with 360p
videos, yet the media player can do 720p at full framerate just fine)
It looks like it was indeed a driver issue. After reverting to an older Xorg version to force compatibility with AMD legacy drivers, my framerate went from 19 FPS to 82 FPS using the test program referenced above.
I referenced the following pages to install the legacy drivers:
