Hardware surface

Hi,

what exactly means “hardware surface”? OK, the
surface is stored in the video cards memory - but
do I have realy random access to it?

Background: I have 36 bitmaps with a total memory
consumption of 150MB (raw RGB 24Bit). I need to
blit parts of them randomly on the screen.
So let’s say I would buy such a modern graphics card
with 256MB memory. Is there a chance that I can store
the whole 150MB of bitmaps in the graphics card and
blit random parts of them on the screen with nearly
no cpu load?
I did this for another project using opengl and a gf5 fx5200
with 128MB RAM (about 70MB of compressed textures)
but the 2^n quadratic format of gl textures is realy
unfavourable for me; and I don’t need any 3d calculation.

Thanks
Leander

ps I’m working under Linux with XFree86 4.x and
usually use the closed source drivers of nvidia.

Leander Seige wrote:

Hi,

what exactly means “hardware surface”? OK, the
surface is stored in the video cards memory - but
do I have realy random access to it?

Provided you lock/unlock your hardware surface correctly, you can acces
it as you want.
See the manpage for SDL_LockSurface/SDL_UnlockSurface

The fact that the surface is in video memory has some implications :
video memory is usually slow to access, so you should minimize
modifications done to hardware surfaces or to anything tored in video
ram (this is the current trend : the video card contains everything
that’s needed for it to work in its own ram : geometry (vertex buffers),
images (textures), more recently programs (shaders) and soon even things
like parametrized/subdivision surfaces).

Background: I have 36 bitmaps with a total memory
consumption of 150MB (raw RGB 24Bit). I need to
blit parts of them randomly on the screen.
So let’s say I would buy such a modern graphics card
with 256MB memory. Is there a chance that I can store
the whole 150MB of bitmaps in the graphics card and
blit random parts of them on the screen with nearly
no cpu load?

It would probably fit, and even if it does not, modern video cards have
AGP that allows you to use system memory as en extension to video memory
(and usually video drivers use a LRE [least recently used] policy to
allocate video memory, so that textures unused for a while will go away
from video memory and free room for another texture).

I did this for another project using opengl and a gf5 fx5200
with 128MB RAM (about 70MB of compressed textures)
but the 2^n quadratic format of gl textures is realy
unfavourable for me; and I don’t need any 3d calculation.

If you are assured of having that video card, it features (like all
video cards from the last 2-3 years or so) an OpenGL extension called
GL_NV_texture_rectangle that allows non-2^n textures.

Thanks
Leander

ps I’m working under Linux with XFree86 4.x and
usually use the closed source drivers of nvidia.

If you want hardware surfaces, you’ll have to use something else than
XFree, as the X11 backend for SDL doesn’t support hardware surfaces :-/

Stephane

See the manpage for SDL_LockSurface/SDL_UnlockSurface

These are only needed for manipulating the surface, right?

modifications done to hardware surfaces or to anything tored in video

Ok, I don’t have to manipulate the surfaces. I only have to blit
subsets of the surfaces to the screen; say I want to blit the subrect
x1,x2,y1,y2 out of surface n to the screen. So once the surface
has been loaded into the video ram the cpu should only give
a bunch of coordinates to the graphics card and no bitmap data
must be transfered from the ram to the card then, I think.

AGP that allows you to use system memory as en extension to video memory

Thats what I want to avoid. I need the performance for other things.

If you are assured of having that video card,

Yes, it has to run only on my computer; no need to make it universal.

GL_NV_texture_rectangle that allows non-2^n textures.

Great! Thanks!

If you want hardware surfaces, you’ll have to use something else than
XFree, as the X11 backend for SDL doesn’t support hardware surfaces :-/

Hm, what would be a good alternative?

Thanks and Greetings,
Leander

Leander Seige wrote:

See the manpage for SDL_LockSurface/SDL_UnlockSurface

These are only needed for manipulating the surface, right?

Yes.

modifications done to hardware surfaces or to anything tored in video

Ok, I don’t have to manipulate the surfaces. I only have to blit
subsets of the surfaces to the screen; say I want to blit the subrect
x1,x2,y1,y2 out of surface n to the screen. So once the surface
has been loaded into the video ram the cpu should only give
a bunch of coordinates to the graphics card and no bitmap data
must be transfered from the ram to the card then, I think.

That’s exactly what OpenGL (or any 3D api, for that matter) does.

AGP that allows you to use system memory as en extension to video memory

Thats what I want to avoid. I need the performance for other things.

If you are assured of having that video card,

Yes, it has to run only on my computer; no need to make it universal.

GL_NV_texture_rectangle that allows non-2^n textures.

Great! Thanks!

If you want hardware surfaces, you’ll have to use something else than
XFree, as the X11 backend for SDL doesn’t support hardware surfaces :-/

Hm, what would be a good alternative?

Considering that NV_texture_rectangle fits your needs and that you don’t
need to modify your data, I would go for plain OpenGL (using SDL or glut
or glx or…) and store the surfaces as OpenGL textures. Blits using 3D
hardware (in your case through OpenGL) are probably the faster blits you
can get.

Also, if you want to spare memory, you can try compressed OpenGL
textures, for example using s3tc. Or you can ask OpenGL to store
textures as RGB5 instead of RGB8. Or try paletted textures. But using
these really depends on your data.

Stephane

Ok, I don’t have to manipulate the surfaces. I only have to blit
subsets of the surfaces to the screen; say I want to blit the subrect
x1,x2,y1,y2 out of surface n to the screen. So once the surface
has been loaded into the video ram the cpu should only give
a bunch of coordinates to the graphics card and no bitmap data
must be transfered from the ram to the card then, I think.

If you want hardware surfaces, you’ll have to use something else than
XFree, as the X11 backend for SDL doesn’t support hardware surfaces :-/

Hm, what would be a good alternative?

Try to use DirectFB if you want real performance. Even though SDL can behave real good in some environments, DirectFB gives more HW support with streth blits, subsurface blits and others using the HW acceleration. The only minus is that it is only limited to a certain chipsets…

That’s exactly what OpenGL (or any 3D api, for that matter) does.

Yes, I know, but I don’t need any 3D calculations, so I thought it
should be possible in 2D with SDL only.

Considering that NV_texture_rectangle fits your needs and that you don’t
need to modify your data, I would go for plain OpenGL (using SDL or glut

ACK, besides that I’d like to use the TwinView capabilities of the
nvidia drivers (dualhead which appears as one single screen to the
XServer). So if SDL doesn’t support hardware surfaces with X - as you
say - OpenGL would be the best choice. I hope the -rectangle extension
will support my bitmaps (unusual format 640x2280).

Also, if you want to spare memory, you can try compressed OpenGL

Yes, already used that … but if possible i’ll use uncompressed ones
for quality :-]

Thanks
Leander

Try to use DirectFB if you want real performance.

Yeah - I forgot that I need the TwinView capabilities
of the nvidia cards, so I have to use X.
I think DirectFB doesn’t support TwinView.

Thanks,
Leander

Leander Seige wrote:

That’s exactly what OpenGL (or any 3D api, for that matter) does.

Yes, I know, but I don’t need any 3D calculations, so I thought it
should be possible in 2D with SDL only.

Well, for sure some 3D transformations will take place BUT :

  • to blit a quad, you need to transform only 4 points. Considering the
    size of your surfaces, you’ll probably be fillrate-limited in this case
    (as opposed to transform limited).
  • 3D transformations are hardware-accelerated on your card anyway, so
    provided you don’t tranform more points per second that your card can
    do, they come for free in a fillrate-limited situation (most cards from
    the last 3 years or so can do a real-world 10 millions vertices per second)
  • using 2D only implies not using the 3D texturing hardware, which is,
    as I said before, the fastest way to blit provided your textures are
    already resident in video memory.
  • also, if you’re concerned about transforming 4 points, I’d like to see
    the rest of your code, because it has to be optimized really well to
    justify trying to optimize a 4-point transformation :smiley:

Considering that NV_texture_rectangle fits your needs and that you don’t
need to modify your data, I would go for plain OpenGL (using SDL or glut

ACK, besides that I’d like to use the TwinView capabilities of the
nvidia drivers (dualhead which appears as one single screen to the
XServer). So if SDL doesn’t support hardware surfaces with X - as you
say - OpenGL would be the best choice. I hope the -rectangle extension
will support my bitmaps (unusual format 640x2280).

You can always split them in more smaller textures if they don’t fit.
And well, they do fit anyway. You can find such info online for most 3D
cards :
http://delphi3d.net/hardware/index.php

Stephane

Hi

  • using 2D only implies not using the 3D texturing hardware,

But OpenGL with a 2D setup (gluOrtho2D) will hopefully use
the 3D texturing hardware. At least - as I said - for another
(similar) project I blitted 800x600/25fps from compressed
textures (OpenGL) on a fx5200/celeron300 with 99.5% cpu idle.

  • also, if you’re concerned about transforming 4 points,

No, I’m not :wink:

I’d like to see
the rest of your code,

It’s realtime analyzing a videostream (camera) to decide which
bitmap to blit on the screen. Thats why I want to have as much
cpu time as possible for this job and let the graphics card do
the rest.

http://delphi3d.net/hardware/index.php

Nice, Thanks!
Leander