[SDL] refreshing my knowledge

M. Egmond sdl at elmerproductions.com
Mon Jan 13 12:19:00 PST 2003

At 2003-01-13 14:55, you wrote:
>On Sun, 12 Jan 2003, José Luis Sánchez wrote:
>So, we can consider that if we have to do a lot of blits, we better put
>the surface in the system memory and blit the final result to vram?
>Another question, where is located the surface returned by SetVideoMode?

It depends what else your CPU might do. If you're playing a very CPU 
intensive game, you might want to use the slower GPU (videocard) to do the 
blitting, so you retain full power of your CPU for the other processing. 
(Or for example if someone might consider running a background application 
that uses a lot of CPU power)

To get the optimal result, you'd have to benchmark the GPU and CPU before 
starting, since each configuration will differ (also the same hardware 
configuration can vary depending on what other programs are running at the 
same time...) and it will also depend on the expected power you will need 
for blitting and other processing.

> > Loudly, those cycles are wasted if you simply keep your CPU waiting for the
> > blit to be completed.  So you might design your program so that it does
> > actually something useful while the GPU is busy.
>And how can I do this? How can i process something while Im blitting?

Theoretically, you can make the videocard do asynchronous blitting 
(theoretically, since I am not sure if and how SDL supports meddling with 
this). This means that the blit-call returns immediately after setting up 
the (vram to vram) blit in the GPU. Only if the GPU-buffer ("blit-queue") 
is full will it wait (or you can tell it to return some kind of 'busy'). 
This means you could design a loop where you do a blit followed by some 
CPU-processing, until the screen is set up. To make it more flexible you 
might design two threads: one does the graphics (blitting only) and the 
other the CPU intensive tasks. If you then make sure the blitting-task has 
a decent wait-function (so it will give up the processor when it's not 
doing anything useful) you make optimal use of both GPU and CPU.

The trick is that with separate threads for GPU and CPU you will win if the 
GPU can do a lot of your work (since your CPU task does not need to wait 
for it), but you won't lose a lot if it can't (since a single extra thread 
shouldn't be much overhead).

M. Egmond

More information about the SDL mailing list