Hi there, Benno! :-)On Saturday 07 April 2001 11:37, Benno Senoner wrote:
On Saturday 07 April 2001 04:09, you wrote:
It is quite possible to write directly to video memory; that’s what the
XFree86 DGA extension is used for. You need write access to /dev/mem to
do this, however.
Yes, as said I can run the app as root, this is not a problem.
The problem is to figure out the startaddress (offsets between row etc),
pixel layout etc etc. (eg if it is RGB, 8bit colormapped etc)
Can SDL used for this stuff, or do I need some XFree calls ?
I’d would be grateful for any hint in that direction
Depending on what you want to do, getting direct access to VRAM may not
improve things; it may even slow things down. The problem is that modern
video cards aren’t really designed for direct access, but for accelerated
rendering. This becomes very noticable when you try to do full frame rate
animation at high resolution on Linux; the bandwidth just doesn’t cut it, as
long as the CPU does the blitting. (And retrace sync is missing as well, but
that’s another story…)
The only way I know of to get real performance on Linux with current driver
archs is to use a 3D API (OpenGL) and rely on hardware 3D acceleration (Mesa,
Utah-GLX or DRI.) I can see basically 3 ways of doing what you want, provided
I’m understanding your problem (lower numbers are generally faster):
-
Draw the display using OpenGL “primitives”, with or without textures.
-
Render in software (perhaps using SDL) into a “small” texture, and then
render that to screen using OpenGL, scaling it up to whatever size you
need, depending on the screen resolution. (You can do this with
interpolation without significant slowdown on most cards these days, if
you prefer a blurred image to big simple [aliazing distorted] scaling.)
-
Do 2, but in 1:1 texture:screen resolution; ie full size. Why not
render directly to VRAM then? Well, software rendering to system RAM is
very fast in relation to doing it to VRAM, while at least some OpenGL
drivers seem to be capable of using busmaster DMA - which is also very
fast on modern cards (AGP in particular), and doesn’t burn CPU cycles.
The net result is that you can use the full busmaster DMA bandwidth
without messing with direct VRAM access. (And you get blending,
transformations and stuff as an extra bonus, BTW. 
Now, I have yet to see some proof of the busmaster DMA actually being used
for texture uploading on a Linux driver… It seems like the code is there
(and BM DMA is used for fetching commands as well), but I’ve failed to get
anywhere near the expected performance so far. Might be me, or the driver -
haven’t tried very hard yet.
Anyway, it’s important to use the exact right format as most cards don’t do
pixel format conversions on the fly when downloading. (Or at least, the
drivers don’t seem to support it.) If you don’t, the driver will silently
chew away quite a few CPU cycles converting your texture before downloading
it. (Could still be faster than direct VRAM access though, at least with a
carefully optimized driver on a fast CPU.)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’