Re: OpenGL vs. SDL for 2D

[Steve Baker <sjbaker1@airmail.net>]

Vesselin Peev wrote:
> 
> > I don't think you'd get much improvement using 3D accelerators for what
> can
> > be done using SIMD instructions, as long as your pack your datatype
> > efficiently, and if the alpha-blending is all you need from the
> accelerator,
> > I wouldn't bother using one. It cuts out a portion of the market, see?
> 
> I know what you are talking about -- SIMD -- the idea you apply same
> instruction to a large chunk of data, but still, would that compare to a
> decent 3D card with hardware OpenGL? If even only a 20% perf. boost is
> possible using 3D hw for the task.

I don't think *ANYTHING* you can do with the CPU - or even with a hardware
blitter can come close to what you can do with textures in OpenGL.

The reason is that when you load your sprites into the graphics card, they
only travel down the bus *once*.  Then, the commands to render the sprite
are tiny compact polygon descriptions.

For small sprites, perhaps your CPU-based implementation is reasonable - but
once they start to get big, you can't possibly come close to the speed of OpenGL.

Then if you even *think* about rotation, transparency, antialiasing, zooming and
layering of sprites...well there is no way you can get close to the RAM bandwidth
of the graphics card.

> > IIRC, SIMD operations for blending textures is still faster than using the
> > gfx cards, as long as your data is in a decent format.

That's got to be bullshit.  Let me explain why.

Let's look at the state-of-the-art in both CPU's and Graphics:

A modern GeForce card can fill textured 24 bit pixels with blending, scaling
and rotation at 8.8GBytes/sec.

Heck even if you just *wrote* a pixel with every single clock tick of a 2GHz
Pentium, you'd not come close to that! ...and that's making the very large
assumption that your RAM could keep up or that somehow all your sprites
would fit into cache and that you have no overhead in any of your loops!

Even if you could manage this major programming feat, you'd come to a grinding
halt because the AGP bus can't transfer that many pixels into the frame buffer
in a second.

The *practical* difference in speed between the fill rate of the GeForce and
the CPU is really more like 100:1 - presuming you need transparency (of course
you do) and much more than that if you need scaling, rotation, etc.  I doubt
you could even clear the screen at 8Gbytes/sec with any current PC's CPU.

This isn't just an attribute of cutting-edge hardware - let's look back a
few years to the very first OpenGL card that worked under Linux:

Compare a vintage Voodoo-1 card (55Mpixels per second textured, Z-buffered,
rotated/scaled/alpha-blended pixel rate) with a 266MHz CPU of a similar
vintage...same deal.  You have to move a (16bit) pixel in just 5 clock
ticks on the CPU...that might *just* be possible - but you are now consuming
100% of your CPU time doing graphics - versus almost nothing if you are
just drawing sprites using the 3D hardware.  Also, you didn't have AGP
back then - so once again, you are limited by the speed of the PCI bus
and the graphics card wins hands-down.

You can also see a trend here.  Over the past few years, we have gone from
the CPU card having 5 clocks per pixel to keep up with the graphics card -
to just one clock tick per pixel.  Graphics cards are getting faster at a
rate 5 times higher than Moore's law would predict.  CPU's are only just
keeping up.  That simple numerical difference covers a wealth of other
things though.  The instruction set of a CPU has hardly changed at all
over all those generations - but graphics cards have gained hardware T&L,
per vertex and per pixel programmability, antialiasing, etc, etc.

If you want to do graphics (either 3D *or* 2D) then the graphics card is
(of course) the place to do it.

If you are doing graphics using that card under Linux then OpenGL is your
only option.

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net