By: Matt Craighead (matt.craighead.delete@this.conifersystems.com),
Room: Moderated Discussions
JasonB (no@spam.com) on 11/13/08 wrote:
---------------------------
>One of the cool things about the 3Dlabs graphics cards was the use of an MMU between the GPU and VRAM.
>
>Rather than the driver having to upload multiple mipmap levels of entire textures
>into VRAM because it didn't know in advance exactly what texels (or even textures)
>would be needed, the MMU could demand-page in the exact texels at the exact mipmap
>levels it needed during rendering, dramatically reducing the amount of VRAM required
>to effectively render a scene compared to an ATI or NVIDIA card. Since 3D graphics
>often has a lot of temporal coherence the VRAM acted as a very effective cache with
>relatively low levels of RAM - VRAM traffic.
MMU-based, interrupt-based demand paging of textures in 3D graphics is *not* a good idea. In fact, it's a really terrible idea for the CPU to have to take an interrupt in the middle of a frame to have to download a bunch of textures. In the meantime, the graphics pipe is stalled!
If the texture data is in locked-down system memory already, your best bet is for the GPU to texture from system memory at reduced performance and to migrate that data into video memory at the next available opportunity.
If the texture data is *not* in locked-down system memory but instead is in regular pageable system memory or on disk, you have much bigger problems. The GPU's kernel driver takes an interrupt and... then what? You can't access pageable system memory in an ISR or even a DPC. You could schedule a worker thread, but when you start looking at interrupt latencies, OS scheduler latencies, kernel virtual address space limitations on 32-bit OS's and the performance costs of mapping and unmapping stuff on demand, security considerations with the kernel reaching directly into an untrusted user-space app, etc. this rapidly starts looking like a worse and worse idea.
Disk would be even worse; consider disk read latencies vs. real-time 3D graphics frame times. If your working set can't fit in RAM or can't be prefetched by the time it's needed, "real-time" is doomed.
This is one of those ideas that sounds great in theory but simply does not work in practice. You will do much better with an intelligent software texture manager in the OGL/D3D driver. 3Dlabs sold you a bill of goods on this one. I would be surprised if 3Dlabs actually implemented half of what their marketing slides claimed in terms of "virtual texturing" support.
--
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com
---------------------------
>One of the cool things about the 3Dlabs graphics cards was the use of an MMU between the GPU and VRAM.
>
>Rather than the driver having to upload multiple mipmap levels of entire textures
>into VRAM because it didn't know in advance exactly what texels (or even textures)
>would be needed, the MMU could demand-page in the exact texels at the exact mipmap
>levels it needed during rendering, dramatically reducing the amount of VRAM required
>to effectively render a scene compared to an ATI or NVIDIA card. Since 3D graphics
>often has a lot of temporal coherence the VRAM acted as a very effective cache with
>relatively low levels of RAM - VRAM traffic.
MMU-based, interrupt-based demand paging of textures in 3D graphics is *not* a good idea. In fact, it's a really terrible idea for the CPU to have to take an interrupt in the middle of a frame to have to download a bunch of textures. In the meantime, the graphics pipe is stalled!
If the texture data is in locked-down system memory already, your best bet is for the GPU to texture from system memory at reduced performance and to migrate that data into video memory at the next available opportunity.
If the texture data is *not* in locked-down system memory but instead is in regular pageable system memory or on disk, you have much bigger problems. The GPU's kernel driver takes an interrupt and... then what? You can't access pageable system memory in an ISR or even a DPC. You could schedule a worker thread, but when you start looking at interrupt latencies, OS scheduler latencies, kernel virtual address space limitations on 32-bit OS's and the performance costs of mapping and unmapping stuff on demand, security considerations with the kernel reaching directly into an untrusted user-space app, etc. this rapidly starts looking like a worse and worse idea.
Disk would be even worse; consider disk read latencies vs. real-time 3D graphics frame times. If your working set can't fit in RAM or can't be prefetched by the time it's needed, "real-time" is doomed.
This is one of those ideas that sounds great in theory but simply does not work in practice. You will do much better with an intelligent software texture manager in the OGL/D3D driver. 3Dlabs sold you a bill of goods on this one. I would be surprised if 3Dlabs actually implemented half of what their marketing slides claimed in terms of "virtual texturing" support.
--
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com