3 ms·

It doesn't have to be this complicated. It only seems complicated because your solutions are stuck in the context of memory mapping. A very simple solution is

It doesn't have to be this complicated. It only seems complicated because your solutions are stuck in the context of memory mapping. A very simple solution is to add another logic layer to GPU processing, like a shader. It could be the "asset shader," it would run on each frame and tells the GPU what assets to start preloading, etc. That would give the programmer tight control over asset loading latencies without having to load everything at once.

vardump 10y ago
> and tells the GPU what assets to start preloading, etc. How does that shader gain information about which portions of the texture are needed at each mipmap level? Or do you just load whole texture and consume memory you don't actually need to render the image. It'd perform badly due to unnecessary I/O causing a long loading time. You'd also waste large portions of GPU RAM. Or does your shader try to guess? Do you attempt to reverse engineer exactly how GPU trilinear texture sampler operates, because otherwise you won't know which parts of asset data is needed -- guess wrong and you get weird artefacts, when GPU samples your texture at a memory location you didn't load. Oops. Rounding differences compared to hardware texture sampler would almost certainly get you. Not sure if it's still true, but at least in past different brand/model GPUs implemented texture sampling slightly differently [1], enough to force you to have a version for many GPU vendors and models. Or do you disable trilinear sampling and use just one mipmap level you somehow pick. You'd get bad image quality, blur and/or aliasing (like moire). Even after considering all that, how are you going to deal with texture atlases? Your way sounds really complicated. Unless you're willing to do rather serious compromises. Robustness, quality or loading time performance. [1]: http://hexus.net/tech/reviews/graphics/747-nvidias-geforce-6800-ultra-gpu/?page=12 http://hexus.net/tech/reviews/graphics/747-nvidias-geforce-6...
- saynsedit 10y ago
  The "shader" would take in the current application-specific description of the scene. This description in theory would be much much much smaller than the corresponding assets required to render the scene. It would be trivial to eagerly bind to the shader. The asset shader API could provide information on the current GPU's texture rendering parameters/quirks.

vardump 10y ago

> and tells the GPU what assets to start preloading, etc. How does that shader gain information about which portions of the texture are needed at each mipmap level? Or do you just load whole texture and consume memory you don't actually need to render the image. It'd perform badly due to unnecessary I/O causing a long loading time. You'd also waste large portions of GPU RAM. Or does your shader try to guess? Do you attempt to reverse engineer exactly how GPU trilinear texture sampler operates, because otherwise you won't know which parts of asset data is needed -- guess wrong and you get weird artefacts, when GPU samples your texture at a memory location you didn't load. Oops. Rounding differences compared to hardware texture sampler would almost certainly get you. Not sure if it's still true, but at least in past different brand/model GPUs implemented texture sampling slightly differently [1], enough to force you to have a version for many GPU vendors and models. Or do you disable trilinear sampling and use just one mipmap level you somehow pick. You'd get bad image quality, blur and/or aliasing (like moire). Even after considering all that, how are you going to deal with texture atlases? Your way sounds really complicated. Unless you're willing to do rather serious compromises. Robustness, quality or loading time performance. [1]: http://hexus.net/tech/reviews/graphics/747-nvidias-geforce-6800-ultra-gpu/?page=12 http://hexus.net/tech/reviews/graphics/747-nvidias-geforce-6...

saynsedit 10y ago
The "shader" would take in the current application-specific description of the scene. This description in theory would be much much much smaller than the corresponding assets required to render the scene. It would be trivial to eagerly bind to the shader. The asset shader API could provide information on the current GPU's texture rendering parameters/quirks.