Some problems with Fullscreen Video Modes

I?m having some trouble with Fullscreen mode. I?m
quite new to SDL so don?t mind if it?s a stupid
question. Some people told me a stupid question is
only an unquestioned question. So I decided to post
this.

My code works allright in windowed mode, but when I
try to run it on fullscreen mode it gets completely
slow! It?s too slow, something like less than 1fps.
that really sucks.

The problem happens only when I try to use alpha
blending and if the colordepth of the loaded images is
different than that of the screen. Did I forget
Something in the code?

Something tells me it?s a common starters mistake.__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/

Well, this is a VFAQ. (It’s probably about time to put this
information on a web site with some code examples and stuff… Or is
there one that I don’t know of?)

Anyway, you’re not really making a mistake. You’ve just hit the
"modern PCs are not designed for software rendering" brick wall.

The problem is that CPU access to VRAM is very slow on modern video
cards. As if that isn’t bad enough, reads are insanely slow; many
times slower than writes. And alpha blending happens to be a
read-modify-write operation…

What you’re really supposed to do is upload your graphics to the
video card and then use the 3D accerator for rendering. That is,
OpenGL or Direct3D, which is what modern hardware is designed for.
The major advantages are that this runs insanely fast on any
reasonably modern hardware, and that you get filtered scaling,
rotation, color modulation, blending and stuff with no significant
performance impact.

However, using 3D acceleration means your game won’t run without 3D
drivers and libs, and without a 3D accelerator, you may actually see
even worse frame rates than you get now. So, this is not an option
unless it’s otherwise motivated to add “3D accelerator with OpenGL
and/or Direct3D drivers” to the minimun system requirements.

There is a simple trick, though: Render into a software shadow
surface, copy (plain blit) to the display surface and then flip.
Repeat for each frame. (Note that if you get a s/w display surface
from SDL, you should not set up a shadow surface of your own. That
would just be a waste of memory and cycles.)

That way, you get fast s/w rendering with alpha and stuff, but you
still perform only writes to VRAM. The primary advantages are that
this works everywhere, and that you can implement your own low level
s/w blitting routines for pixel level effects. (You can do that
with OpenGL and Direct3D, but you can’t do things the same way, and
it still has major performance issues on most systems.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Friday 02 April 2004 07.55, Romulo Gnomo wrote:

I?m having some trouble with Fullscreen mode. I?m
quite new to SDL so don?t mind if it?s a stupid
question. Some people told me a stupid question is
only an unquestioned question. So I decided to post
this.

My code works allright in windowed mode, but when I
try to run it on fullscreen mode it gets completely
slow! It?s too slow, something like less than 1fps.
that really sucks.

The problem happens only when I try to use alpha
blending and if the colordepth of the loaded images is
different than that of the screen. Did I forget
Something in the code?

Something tells me it?s a common starters mistake.

Is it as slowing with SDL_HWSURFACE and SDL_SWSURFACE ?

If Romulo Gnomo launch is fullscreen application with alpha blending in
a SDL_HWSURFACE surface will it perform faster ?

I use doublebuffer for conveniance, and find it interesting to
draweverything before fliping the screen. Does this really matter ? I
mean, I ve never noticed any slow down either in HW or SW

les.

David Olofson a ?crit :> On Friday 02 April 2004 07.55, Romulo Gnomo wrote:

I?m having some trouble with Fullscreen mode. I?m
quite new to SDL so don?t mind if it?s a stupid
question. Some people told me a stupid question is
only an unquestioned question. So I decided to post
this.

My code works allright in windowed mode, but when I
try to run it on fullscreen mode it gets completely
slow! It?s too slow, something like less than 1fps.
that really sucks.

The problem happens only when I try to use alpha
blending and if the colordepth of the loaded images is
different than that of the screen. Did I forget
Something in the code?

Something tells me it?s a common starters mistake.

Well, this is a VFAQ. (It’s probably about time to put this
information on a web site with some code examples and stuff… Or is
there one that I don’t know of?)

Anyway, you’re not really making a mistake. You’ve just hit the
"modern PCs are not designed for software rendering" brick wall.

The problem is that CPU access to VRAM is very slow on modern video
cards. As if that isn’t bad enough, reads are insanely slow; many
times slower than writes. And alpha blending happens to be a
read-modify-write operation…

What you’re really supposed to do is upload your graphics to the
video card and then use the 3D accerator for rendering. That is,
OpenGL or Direct3D, which is what modern hardware is designed for.
The major advantages are that this runs insanely fast on any
reasonably modern hardware, and that you get filtered scaling,
rotation, color modulation, blending and stuff with no significant
performance impact.

However, using 3D acceleration means your game won’t run without 3D
drivers and libs, and without a 3D accelerator, you may actually see
even worse frame rates than you get now. So, this is not an option
unless it’s otherwise motivated to add “3D accelerator with OpenGL
and/or Direct3D drivers” to the minimun system requirements.

There is a simple trick, though: Render into a software shadow
surface, copy (plain blit) to the display surface and then flip.
Repeat for each frame. (Note that if you get a s/w display surface
from SDL, you should not set up a shadow surface of your own. That
would just be a waste of memory and cycles.)

That way, you get fast s/w rendering with alpha and stuff, but you
still perform only writes to VRAM. The primary advantages are that
this works everywhere, and that you can implement your own low level
s/w blitting routines for pixel level effects. (You can do that
with OpenGL and Direct3D, but you can’t do things the same way, and
it still has major performance issues on most systems.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Les HauSsebons wrote:

My code works allright in windowed mode, but when I
try to run it on fullscreen mode it gets completely
slow! It?s too slow, something like less than 1fps.
that really sucks.

The problem happens only when I try to use alpha
blending and if the colordepth of the loaded images is
different than that of the screen. Did I forget
Something in the code?

when you are using SWSURFACES then you should allways call
SDL_DisplayFormat() for each of your images.

clemens

Hello, David!

DO> The problem is that CPU access to VRAM is very slow on modern video
DO> cards.

Can you explain why this happens ? For example, my video memory is SDRAM
(GF2MX400), running on 200MHz, my main SDRAM memory running at 133MHz CS:2,
I’ve Tualatin 1.5GHz CPU. So video memory ram in theory must have the same
speed at least, as usual RAM, isn’t it ?

DO> As if that isn’t bad enough, reads are insanely slow; many times
DO> slower than writes.

Under QNX6 I’ve vice versa situation, it reads vmemory fast, but write is
damnely slow. I’ve disabled write operations during alpha-blitting and
reading operations from vmem works almost with the same speed as main
memory.

DO> And alpha blending happens to be a
DO> read-modify-write operation…

Yep, I’ve 80-100 times perfomance loss (measured via RDTSC on x86) during
vmem->vmem or mem->vmem operation, why this happens from the hardware point
of view ?

I’ve found this only on alpha-blitting, not on color key blitting and not on
a usual blitting. I’m blitting from main memory to fullscreen HWSURFACE
(it’s a write operation !) and it’s really slow - 2-3 fps, while RLE
accelerated color key blitting is around 130fps with the same configuration
(measured via testvidinfo -benchmark).

I’ve tested different alignes (4, 8, 32 bytes, even 4K align), it doesn’t
helps significally, only saves some CPU tics.

P.S. I’ve added alpha blitting and alpha+colorkey blitting benchmarks to the
testvidinfo, I’ll send patches soon :slight_smile:

With best regards, Mike Gorchak. E-mail: @Mike_Gorchak

DO> The problem is that CPU access to VRAM is very slow on modern video
DO> cards.
Can you explain why this happens ? For example, my video memory is SDRAM
(GF2MX400), running on 200MHz, my main SDRAM memory running at 133MHz CS:2,
I’ve Tualatin 1.5GHz CPU. So video memory ram in theory must have the same
speed at least, as usual RAM, isn’t it ?

I don’t agree that it’s “Very slow” (this has not been my experience, but
terms like these are relative/subjective anyway), but certainly slower
than main system memory. There is bus protocol overhead for AGP/PCI that
doesn’t exist for SDRAM accesses.

Yep, I’ve 80-100 times perfomance loss (measured via RDTSC on x86) during
vmem->vmem or mem->vmem operation, why this happens from the hardware point
of view ?

Not to sound too cynical, but is this an AMD based machine? The XP2400+
machine I have is over 2X slower than a 2Ghz P4 system I’ve got - with the
same TI4600 video card and I’ve had other similar experiences with other
AMD boxen.

If you’re looking for the best performance on reading/writing to/from
video RAM, consider this:

  1. Do as many batch transactions as you can. Give a chance for the back to
    back writes to linear addresses to be batched by the chipset.
  2. Avoid read/modify/write operations on small data sizes
  3. Avoid unaligned accesses (4 byte boundaries are the smallest you want
    to go)
  4. Assemble your frames in main memory and avoid using video card
    backbuffer surfaces. As you’ve found, main memory is ALWAYS going to be
    faster than video card memory.

–>Neil-------------------------------------------------------------------------------
Neil Bradley "Your mistletoe is no match for my T.O.W. missile!"
Synthcom Systems, Inc. - Santabot - Futurama
ICQ #29402898