Refreshing my knowledge

I would like to confirm some things about blits:

video ram to video ram blits are faster
writing directly to vram (ie. modifying pixels) is very slow.
system ram to video ram blits are a bit slower

There is some difference if there is support for accelerated blits?–
Roger D. Vargas | El sistema se apagara en 5 segundos.
ICQ: 117641572 | Salvese el que pueda!
Linux User: 180787 |

Roger D. Vargas wrote:

video ram to video ram blits are faster

“are fastest”

writing directly to vram (ie. modifying pixels) is very slow.

True.

system ram to video ram blits are a bit slower

“are significantly slower than video-to-video blits”, but they are a lot
faster than modifying each pixel individually.

There is some difference if there is support for accelerated blits?

I imagine video-to-video blits are still fastest in this situation, but
I haven’t tested it. system-to-video blits just aren’t quite as slow as
when doing this without 2D acceleration in this situation.

“Roger D. Vargas” escribi?:

I would like to confirm some things about blits:

video ram to video ram blits are faster
writing directly to vram (ie. modifying pixels) is very slow.
system ram to video ram blits are a bit slower

There is some difference if there is support for accelerated blits?

The scenario is actually somewhat more complex.

Speaking on 2D only, you can optimize for a variety of tasks but generally
speaking, the goal is to use the least CPU for drawing.

With this goal in mind, you’ll see video-to-video blits are better, IF they can
be accomplished by the GPU (i.e.: if there are accelerated hardware-to-hardware
blit available). Video-to-video blits via software is a very time-consuming
task and might be avoided.

On any AGP video card, you can also use the graphics processor (GPU) for
transfers between system RAM and video RAM. The GPU has direct access to the
AGP aperture frame, usually mapped at the very end of the address space.
DirectX calls this space “local vram” or the like.

Note that the GPU might be actually SLOWER than the main CPU. In fact, the
FASTEST blits are from system RAM to system RAM. Just remember: the goal is to
use CPU cycles as little as possible.

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.

My point here is: don’t think only on plain blit speed, but overall
performance.

Regards,
Wizord.

Video to video is fast, system to video (or writing to vram) is fast,
system to system is really fast, and video to system (or reading vram)
is really slow.On 06-Jan-2003, Roger D. Vargas wrote:

I would like to confirm some things about blits:

video ram to video ram blits are faster
writing directly to vram (ie. modifying pixels) is very slow.
system ram to video ram blits are a bit slower


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030111/e5367fc5/attachment.pgp

“Roger D. Vargas” escribi?:

I would like to confirm some things about blits:

video ram to video ram blits are faster
writing directly to vram (ie. modifying pixels) is very slow.
system ram to video ram blits are a bit slower

There is some difference if there is support for accelerated blits?

The scenario is actually somewhat more complex.
I know, but the idea is to give some “quick guides” about blitting.

Note that the GPU might be actually SLOWER than the main CPU. In fact, the
FASTEST blits are from system RAM to system RAM. Just remember: the
goal is to
use CPU cycles as little as possible.
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?

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?On Sun, 12 Jan 2003, Jos? Luis S?nchez wrote:


Roger D. Vargas | El sistema se apagara en 5 segundos.
ICQ: 117641572 | Salvese el que pueda!
Linux User: 180787 |

At 2003-01-13 14:55, you 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).

Regards,
M. Egmond>On Sun, 12 Jan 2003, Jos? Luis S?nchez wrote:

Thanks, you have cleared my mind a lot.On Mon, 13 Jan 2003, M. Egmond wrote:


Roger D. Vargas | El sistema se apagara en 5 segundos.
ICQ: 117641572 | Salvese el que pueda!
Linux User: 180787 |