[SDL] software blit speed in windows and linux
Author
i finally did some simple benchmarks to compare sdl's software blitting speed in both windows and linux. windows was about 50% faster in every test. is this normal? if so, what's the reason for such a drastic difference?
Hardware acceleration through DirectDraw.
The one for linux goes through whatever GDI equivelant there is for X. It would be faster if it was built over DirectFrameBuffer. But most people try to use OpenGL anyways.
The one for linux goes through whatever GDI equivelant there is for X. It would be faster if it was built over DirectFrameBuffer. But most people try to use OpenGL anyways.
Some of that difference might be because of the video drivers. If you used an ATI card, their Linux drivers are pretty crappy last time I checked. Did you perform this test on the same machine, and did you remember to install the proper video drivers for Linux? Also one more thing I think I heard was that the resolution of the timer in Windows is rather poor, which could create a small advantage or disadvantage. What was the total time to run the test? If it was only a few milliseconds, you should make it much longer so there's less noise due to your timer resolution. [smile]
Author
the test machine:
p2 350mhz
192mb pc100 sdram
integrated ati rage lt pro agp 4mb (mach64...)
windows xp pro w/ sp2
debian 3.1, xfree86, gnome
all tests were run with sdl software blitting in 16 and 32bit in multiple resolutions. there's no proper driver for xp and mach64 support requires too much hassle under x windows. according to sdl i can't get hardware surfaces in either case.
SDL_GetVideoInfo returns this under both windows and linux:
hw_available: 0
wm_available: 1
blit_hw: 0
blit_hw_CC: 0
blit_hw_A: 0
blit_sw: 0
blit_sw_CC: 0
blit_sw_A: 0
blit_fill: 0
video_mem: 0
BitsPerPixel: 32
if sdl is actually using directx's software blitting, is it possible that it's 50% faster than sdl's software blit?
p2 350mhz
192mb pc100 sdram
integrated ati rage lt pro agp 4mb (mach64...)
windows xp pro w/ sp2
debian 3.1, xfree86, gnome
all tests were run with sdl software blitting in 16 and 32bit in multiple resolutions. there's no proper driver for xp and mach64 support requires too much hassle under x windows. according to sdl i can't get hardware surfaces in either case.
SDL_GetVideoInfo returns this under both windows and linux:
hw_available: 0
wm_available: 1
blit_hw: 0
blit_hw_CC: 0
blit_hw_A: 0
blit_sw: 0
blit_sw_CC: 0
blit_sw_A: 0
blit_fill: 0
video_mem: 0
BitsPerPixel: 32
if sdl is actually using directx's software blitting, is it possible that it's 50% faster than sdl's software blit?
Part of that may be Linux's use of the X Window System for graphics. The actual efficiency of X is hard to measure, but in my experience it's traditionally slower than Windows, especially on low-end machines.
It shouldn't make a 50% difference though.
It shouldn't make a 50% difference though.
Software blitting should be more or less identical in speed:
1. Check that you actually are using software blitting in Windows - SDL is capable of using DirectDraw to accelerate some blits.
2. Ensure that your Linux video drivers are correctly set up - in particular, ensure that you have MTRR enabled in the kernel (which is not specific to video drivers, but helps, especially on AGP systems).
X may be considered inefficient by some, but it should not affect blitting speeds significantly.
There is also a (slight?) possibility that SDL is doing a colour depth conversion. Ensure that it isn't (or ensure that it's doing the same one on both at least). If this was the case however, I'd expect a lot more than a 50% drop in speed.
Mark
1. Check that you actually are using software blitting in Windows - SDL is capable of using DirectDraw to accelerate some blits.
2. Ensure that your Linux video drivers are correctly set up - in particular, ensure that you have MTRR enabled in the kernel (which is not specific to video drivers, but helps, especially on AGP systems).
X may be considered inefficient by some, but it should not affect blitting speeds significantly.
There is also a (slight?) possibility that SDL is doing a colour depth conversion. Ensure that it isn't (or ensure that it's doing the same one on both at least). If this was the case however, I'd expect a lot more than a 50% drop in speed.
Mark
Author
it turns out my benchmarks weren't exactly accurate... i got some files mixed up copying between os's. i wrote up a new test and compiled with same flags under gcc and mingw. both tests were identical resolutions, bitdepths, etc. software blit speeds were identical. updating the screen, however, is nearly twice as fast under windows. is this a problem in x windows or is it more likely to be my graphics driver in linux?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
