[SDL] refreshing my knowledge
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).
More information about the SDL