Comment by russli1993 | Hacker News Reader

Comment by russli1993 | Hacker News Reader

Parent Full thread

I think you missed the real point: Textures stored on the SSDs is now byte addressable by the texturing unit on the GPU. When the texturing unit issue a read for texture data, the read can now go directly to the SSD controller, and SSD controller issue NVMe commands to read the data. The texture decompression block sits between the GPU and SSD controller, decompresses the texture at line speed. This way, the GPU can read the texture at the exact detail levels given by the amount of pixels covered by the texture. It gives a texture infinite mips level. The GPU can also place the texture data needed for the current frame in the GPU memory, GPU memory becomes more like a cache for textures. This reduce GPU memory usage. Imagine you want to render a camera flying through a forest. Before you need the texture for the trees and have multiple version of them for far away trees and nearby trees. As the camera flies over, you transition from the low detail texture to the most detailed texture. That is why you see the texture pop in in today's games. Going forward, you just need the most detailed texture, and have the GPU automatically sample the texture according to the pixel needs to be rendered. There will be no stepping in between, it will be continuous. This solves texture pop in at a fundamental level.

Another benefit is reduce CPU involvement. Textures are fundamentally stored on disk, and GPU needs to access that data for rendering. Before we would have the CPU use OS's filesystem storage stack, read a file block, decode the texture in CPU memory, copy the texture to GPU memory using PCI-e, and ask the GPU to render with that data. This method allows the GPU directly read from a SSD, bypassing all of the steps in between. As SSD becomes faster and faster, OS's filesystem is becoming the bottleneck.

> GPU directly read from a SSD, bypassing all of the steps in between

Ehh... unless you have more specific knowledge that’s still under NDA, the reasonable assumption is that the CPU still mmap()es the file into the GPU’s address space, and then the CPU pages in data from the SSD as the GPU generates page misses. Which is technically possible on PCs today, but isn’t done because you can’t assume fast SSDs and you definitely can’t assume shared memory. (actually I’m pretty sure discrete GPUs can generate page misses for mapped CPU memory, but I’m not certain which graphics APIs really let that happen)

Better be at least 2 MB pages then. 5.5M (max. 22 GB/s compression output on PS5) page faults per second for 4 kB pages might otherwise ruin this scheme a bit...

2 MB page size would reduce this to "just" 11k page faults per second.

I know nothing about this, but wouldn't most textures be quite small, and with a large page size you might end up reading in much more than you need, making it often worse than useless?

Transparent superpages solve this

http://u.cs.biu.ac.il/~wiseman/2os/superpage/navaroo1.pdf

That's 113 pages, does this really cover the issue of reading too much? IF so, I'll try and find the time.

I mean I'm not complaining about TLB issues which large pages do better at for obvious reasons, but thrashing the TLB is likely to be a lot cheaper than reading too much from the disk.

FreeBSD superpage max size on amd64 is 1GB

edit: and there have been SPARC CPUs with memory controllers that can do 256GB pages

You do realize the GPU can just read it from the physical address space and not via the CPUs MMU. It's not an innovation. There is still a lot of level3 Bus transactions. If the SSD had two buses, with 1 directly to the GPU (read only type) there would be less pressure on the level3 bus and that would speed things up.

the reasonable assumption is that the CPU still mmap()es the file into the GPU’s address space, and then the CPU pages in data from the SSD as the GPU generates page misses.

You seem to know quite a bit about this - just wondering - how does this work? The GPU can generate PCIe bus traffic to do RAM reads or writes, but how does it cause a page fault in the CPU? Is this some kind of IOMMU? Is there any place I can read more about this?

APU, shared memory controller, unified memory address space.

I don't think the GPU can generate page faults in the traditional sense (which core would #PF be delivered to?). The CPU has to pre-fetch data before the GPU tries to use it. On the PS5, the GPU may be able to issue read requests directly to the IO coprocessor and have it load data off the SSD, run it through the decompressor, place the data into the requested DRAM addresses, and invalidate the necessary cache lines in any GPU or CPU cores. But I'm not sure that the PS5 can actually do that with zero CPU involvement.

Texture streaming is a thing in current gen https://www.youtube.com/watch?v=mvdTtl27TpM

Reply on news.ycombinator.com