By: anon (a.delete@this.b.d), April 24, 2013 4:23 pm
Room: Moderated Discussions
aaron spink (aaronspink.delete@this.notearthlink.net) on April 24, 2013 11:01 am wrote:
> the next gen consoles and their associated memory architectures might make ultra large texture
> games more common place and therefore provide a quality advantage to a GT3e like design.
The ultra large textures simply won't be implemented like that. The next gen consoles use virtual texturing, which is sort of virtual addressing for textures. A miss won't cause the missed page to be loaded, but instead a lower-quality mipmap level will be used. AMD has hardware support for this. Then between frames, the program figures out what textures it needs, and populates them.
In such schemes, textures are typically stored in RAM, but compressed with some sort of entropy coding scheme (like jpeg).
The net effect is that the pressure on the gpu ram goes down, not up. And it really doesn't take all that much from the PCIe bus. Larger textures will not help GTe.
What might help is when programmers mix and match GPU and CPU processing to do separate parts of the rendering pipeline. This will very likely happen on next gen. For example, there are a lot of screen-space effects that are fundamentally a pretty bad fit for the GPU programming model of lots of independent tasks. A single CPU core scanning over the framebuffer can do various algorithms at a fraction of the cost of doing them on the GPU, freeing the GPU to other tasks. This is a non-starter on present systems because the cost of shuffling the framebuffer there and back is just too large, but would fit the shared memory system pretty damn well.
> the next gen consoles and their associated memory architectures might make ultra large texture
> games more common place and therefore provide a quality advantage to a GT3e like design.
The ultra large textures simply won't be implemented like that. The next gen consoles use virtual texturing, which is sort of virtual addressing for textures. A miss won't cause the missed page to be loaded, but instead a lower-quality mipmap level will be used. AMD has hardware support for this. Then between frames, the program figures out what textures it needs, and populates them.
In such schemes, textures are typically stored in RAM, but compressed with some sort of entropy coding scheme (like jpeg).
The net effect is that the pressure on the gpu ram goes down, not up. And it really doesn't take all that much from the PCIe bus. Larger textures will not help GTe.
What might help is when programmers mix and match GPU and CPU processing to do separate parts of the rendering pipeline. This will very likely happen on next gen. For example, there are a lot of screen-space effects that are fundamentally a pretty bad fit for the GPU programming model of lots of independent tasks. A single CPU core scanning over the framebuffer can do various algorithms at a fraction of the cost of doing them on the GPU, freeing the GPU to other tasks. This is a non-starter on present systems because the cost of shuffling the framebuffer there and back is just too large, but would fit the shared memory system pretty damn well.