Some real world SDL 2D vs. glSDL figures

SDL Development
1

For those of you who don’t dare try Kobo Deluxe due to the risk of
getting caught :wink: here are some initial benchmark figures:

Test system:
	CPU:	Celeron 633
	GFX:	ATI Rage 128 "PF" 32 MB
	RAM:	384 MB
	X:	XFree86 4.0.3-7mdk
	OS:	Mandrake 8.0 (Linux 2.4.3-<something>mdk)


Resolution (screen)	SDL		glSDL------------------------------------------------------
896x896 (1280x1024)	18 fps		39 fps
672x672 (960x720)	30 fps		50 fps
448x448 (640x480)	62 fps		56 fps
224x224 (320x240)	200 fps		62 fps

Note that Kobo Deluxe only updates the playfield area every frame
(applies to SDL 2D as well as glSDL modes) - so the actual screen area
that counts to fill rate is significantly smaller than the full screen.

It’s pretty obvious that this system isn’t taking glSDL’s abuse of OpenGL
very well - you’d have to go beyond 640x480 to get better performance
with glSDL even for a fullscreen scrolling game. I’m not sure how the
Celeron compares to my main development P-III 933 in raw power, but at
least I’m pretty sure that the unoptimized code with frequent mixing of
integers and floats isn’t helping… heh

So, why is glSDL so slow? (Well, on this machine, at least…)

* Pages of unoptimized code with lots of float/int casts.

* Possibly significant amounts of function call overhead.

* Most surfaces are using one OpenGL texture each (!), so...

* ...there's *loads* of texture binding going on!

* glSDL alpha blends every single pixel of all surfaces
  with alpha, whereas SDL 2D is using RLE to skip transparent
  areas. (Makes a *big* difference since Kobo DL has a window
  frame that covers the whole render area! It also seems like
  this card has a rather significant alpha blending penalty,
  compared to the G400.)

Anyway, this is quite different from the situation on my P-III 933/Matrox
G400 system. On that machine, OpenGL outperforms SDL 2D even in 320x240
for “simple” applications, and achieves speedup factors in the range of 3
through 5 times the SDL 2D speed in higher resolutions! I’ll post the
benchmark figures for that machine tomorrow. :slight_smile:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’

2

For those of you who don’t dare try Kobo Deluxe due to the risk of
getting caught :wink: here are some initial benchmark figures:

I tried it on my machine (Athlon 950, 128M ram, TNT2 w/nvidia 2313 drivers.
The speed was excellent (near 300 fps at 1280x1024), but the game segfaulted
whenever I tried to do anything.

I’d recommend you patch the CVS version of SDL to have the GL backend, and
post the patch (probably on your website, since it’s likely to be large). If
it looks good, maybe Sam will include it into SDL and we can all have really
fast 2D on our nvidia cards :)On Tuesday 11 December 2001 02:52 pm, you wrote:

–
-Ray

3

For those of you who don’t dare try Kobo Deluxe due to the risk of
getting caught :wink: here are some initial benchmark figures:

I tried it on my machine (Athlon 950, 128M ram, TNT2 w/nvidia 2313
drivers. The speed was excellent (near 300 fps at 1280x1024), but the
game segfaulted whenever I tried to do anything.

Might be caused by one or more of the many bugs in that version… For
example versions prior to 0.4-pre4 (uploaded a few hours ago!) ignore the
maximum texture size limit - and some drivers just try to do what you
tell them to! heh (For example, my G400 setup would take 2048x2048
textures, even though the card can’t only handle up to 1024x1024
correctly. Weird things happen, although I never got it to crash that
way.)

The current version shouldn’t at least not try doing things that aren’t
supposed to work.

I’d recommend you patch the CVS version of SDL to have the GL backend,
and post the patch (probably on your website, since it’s likely to be
large).

Well, the current code is about 2000 lines of source. Is that large? :slight_smile:

Either way, there’s still quite some work to do first. Tiling across
multiple textures in both directions is still missing (vertical only and
horizontal only works in 0.4-pre4), and the code could use quite a bit of
optimization, I think. After that, the code has to be changed to fit
SDL’s internal design, and it has to be adapted to interface with SDL as
a backend rather than an application.

If it looks good, maybe Sam will include it into SDL and we can
all have really fast 2D on our nvidia cards :slight_smile:

Well, you shouldn’t need an nVidia to beat the average P-III CPU. Here
are some benchmark figures from the current version on my G400, which has
low fillrate even compared to at old GeForce 256! Seems like the driver
is also much slower than yours… (From the ChangeLog of 0.4-pre4.)

         P-III 933, Matrox G400, XFree86 4.1.0-17mdk:
            Resolution      SDL 2D  glSDL   ratioOn Wednesday 12 December 2001 06:13, Ray Kelm wrote:

On Tuesday 11 December 2001 02:52 pm, you wrote:
-----------------------------------------------
1280x1024 16 60 3.8
960x720 28 102 3.6
640x480 62 202 3.3
320x240 227 205 0.9

      Note that OpenGL is pumping quite a bit more pixels
      than SDL's RLE blitter in this game, due to the alpha
      blended window frame. Here are the results with no
      frame:
         P-III 933, Matrox G400, XFree86 4.1.0-17mdk:
            Resolution      SDL 2D  glSDL   ratio
            -----------------------------------------------
            1280x1024       18      93      5.2
            960x720         32      163     5.1
            640x480         70      205     2.9
            320x240         256     205     0.8
      Notice how glSDL appears to win even more in higher
      resolutions, while it loses a little to SDL 2D in the
      low end, where fill rate becomes next to insignificant
      to OpenGL.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | -------------------------------------> http://olofson.net -’