Eric Vidal wrote:
Maybe you could expose such fonctionality through suitable OpenGL
extensions like :http://oss.sgi.com/projects/ogl-sample/registry/EXT/pixel_buffer_object.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt
Hmmm, that looks promising. I can theoretically catch all queries for
OpenGL functions from SDL to see whether the app is requesting a vertex
buffer object, then redirect them to my own functions that allocate the
memory in the ps2stuff area.Actually, should I do this? Or should I just modify ps2gl so that the
extension is officially supported?
Well, this definitely doesn’t belong to SDL if you ask me. It’s really
about making ps2gl closer to “standard” OpenGL and as such is not SDL
related.
Also, you could probably do an implementation of OpenGL display lists
the same way. Between display lists and vertex buffers, most OpenGL
applications will be covered performance-wise.
For the textures, you have to allocate and copy the texture to this
specially allocated memory (the OpenGL texture Object which got
standardized in OpenGL 1.1 allows doing just that). That’s really
…
So what you describe falls very well into the current graphics
hardware
trend. Or maybe I’m missing something.Oops… here’s what’s missing in my description – ps2gl isn’t a real
OpenGL library. It does have texture objects, but getting them to work
requires that the texture itself be stored in ps2stuff-managed DMA
memory, just before passing the texture data to glTexImage2D.
You know what ? That’s exactly the same as AGP memory : AGP memory has
to be allocated explicitly by the driver, and then it can be used to
upload textures using DMA and also for AGP texturing when there’s not
enough video memory available. Most 3d video drivers have to solve this
problem. So once again, what you describe just sounds like a "standard"
video adapter to me. It’s just hidden by the driver usually, but I can
assure you it’s there.
(And
like I said in my previous post, there’s still a weird thing going on
with all the GS slots and areas and whatnot. My nose is bleeding.)Another weird thing about this is that ps2gl’s glTexImage2D (and
actually most of its other functions) won’t copy the data – it will
just update some internal pointers. I don’t know why it was designed
this way – perhaps to conserve memory?
That’s probably the only reason. There’s only 32 Mb, right ?
(I can’t seem to think it’s
performance-related because textures are usually preloaded anyway,
hence copying shouldn’t be a big deal except when memory is scarce.)
If you aren’t too concerned about memory (or if you can make some of
the buffers -namely the dma buffers- temporary) I still think you can
implement the “real” glTexImage calls (i.e. withouth imposing the burden
of allocating texture memory to the application).
Allocating DMA memory and copying data around during glTexImage is not
that problematic. That call is expected to be slow anyway.
That might sound like a lot of work, but in the end, I think having an
OpenGL-compliant driver opens the door for a lot of interesting ports 
Stephane