On Wed, 16 Feb 2005 16:18:32 +0100, Martijn Sipkema <[EMAIL PROTECTED]> wrote: > [...] > > > Being able to read huge textures from system memory would be > > > a nice feature anyway. > > > > Reading from system memory in this way was dropped as a simplification > > and security feature. > > I think most graphics hardware is able to read/write directly to system memory > and with large textures and offscreen windows using a lot of memory it would > be inconvenient to not be able to store them in system memory without losing > hardware rendering.
This issue has been discussed and addressed. The idea is to use the graphics memory as a large cache for textures. When rendering is to be done, software will shuffle textures around to make sure that the necessary textures are in graphics memory. > > The security part I don't really understand. Do you mean to not provide > any way for the graphics hardware to write to system memory? I don't > see how reading from system memory can be avoided... > > It may be a simplication, but it is also, IMHO, a serious drawback. > > One might even want to have local memory act as a cache for system > memory, but you'd need the graphics hardware to be able to read/write > to system memory to be able to do so also.. There's a DMA interface that the software will use to move data in and out of graphics memory. That talks to host memory. There is no serious drawback to this approach. In fact, it's seldom more efficient to access a texture in host memory than to move the whole thing into graphics memory and access it there. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
