The only feature of DirectX which I can’t really do quickly on OpenGL is update a procedurally created texture in situ. This requires a subload of the updated part of the image. I’m quite happy to let the GL do the rendering of the updated texture.
These days with AGP4 and fast host->gfx connections on other platforms, it’s not too bad unless you have a large area to update.
Which I do…
Direct texture memory access is not a good thing. It may help in cases where you have a lot of procedural stuff, but it cuts a lot of freedom for the hardware developers since they are forced to have the textures structured in a certain way in memory. The ability to directly access buffers and textures in DX won’t be available anymore in DX8.
The best way to implement procedural stuff in to use rendering-to-texture, which is sadly enough not yet possible in OpenGL, but I hope it’ll be possible in “OpenGL 1.3”
The only problem with rendering to texture is that you’re limited to the primitives/commands available which is why you want to access the memory directly. If I wanted to do this I could render to the frame-buffer and use glCopyTexSubImage2D which is about equivalent.
It was only a thought. nVidia has an extension which allows access to AGP or video memory, so I thought, why not texture memory. They already of a Fences extension to protect that memory…
Slightly-offtopic-but-kind-of-related question that’s been nagging at me lately…
AFAIK, Windows can trash the contents of vidmem without any warning (eg in BSOD-type situations) and for this reason OpenGL drivers keep copies of all vidmem texture data in main memory.
The question is, if I’m using GL to create procedural textures I may be avoiding the overhead of a texture upload, but is the driver going to have to download a backup copy over the AGP bus? That would suck in a big way.