8 ms·

Splash screens and loading bars vanish. Everything is just THERE. I'm not sure I agree with this. It might be more convenient to have a filesystem-like interfa

Splash screens and loading bars vanish. Everything is just THERE. I'm not sure I agree with this. It might be more convenient to have a filesystem-like interface, but at the end of the day everything still has to be loaded into the (rather limited) GPU memory at some point. Most CPU applications can handle RAM swapping from disk, but I really doubt that big games could maintain 60fps if even a few assets needed re-loading. If a frame is 16ms, and the best consumer SSDs are around 2GB/s, You can only load 33MB of assets in a one frame in a best-case scenario.

hartror 10y ago
I suspect if anyone had thought through this it would be John Carmack. His game design skills can be called into question. His 3D engine skills are second to none[1]. [1] As an individual. I suspect why we haven't see as much from him since Quake 3 is that his skills don't scale to a team.
- ralfd 10y ago
  > I suspect why we haven't see as much from him since Quake 3 is that his skills don't scale to a team. He did other stuff like rocket design and all that VR/Oculus Gear stuff
- joakleaf 10y ago
  > I suspect why we haven't see as much from him since Quake 3 Not quite accurate. Since Quake 3 he made Unified lighting and shadowing (for Doom 3) and Megatextures (for Quake 5 and Rage). I can't really think of any other major paradigm shifts over the last 10-15 in game graphics engines. There are lots of little improvements everywhere, but they seem more evolutionary than the revolutionary steps we saw in the 90s (textureMapping, raycasting, BSPs, PVS, lightmaps, Sorted edge rasterization, bilinear filtering, bezier-surferaces, shaders, unified lighting/shadowing and beam trees, etc.).
  - NTripleOne 10y ago
    Let's be honest though, did anyone actually like megatextures? From the consumer's point of view, all they ever did was have bad AMD compatibility and streaming issues on every platform.
    - MLR 10y ago
      I think for Rage it was an idea ahead of its time, but they're still used in the new Doom which doesn't seem to have the same issues and has been praised for good optmisation.
      - Zardoz84 10y ago
        I saw these technique on the original Unreal Tournament.
        Aeolos 10y ago
        The original Unreal Tournament was not using megatextures. There was simply no hardware support for that.
      - jsheard 10y ago
        I believe the new Doom still uses virtual textures to an extent, but they seem to have given up on the idea of using it to apply unique texture assets to every surface in the game as they did in Rage. Without globally unique textures Megatexture goes from a paradigm shift to just an implementation detail, unfortunately.
    - SCdF 10y ago
      Rage was gorgeous. The game was terrible, but it was incredibly pretty, mostly because of megatextures. Some pundit (TotalBiscuit?) referred to it looking like a moving painting, and in places it really was that breathtaking. Again, the game was unfortunately a few fun sections interspersed with really un fun things, but that has nothing to do with the tech. (FWIW I ran it on AMD and it had major problems, and then a year or so later it was perfect. AFAICT they patched most of the issues away on PC)
saynsedit 10y ago
I was facepalming too while reading this. I'd expect Carmack to understand the ugly truth behind mmap: it's not free. It's more than not free, demand-paging actually adds significant cost: TLB flushes aren't performance friendly. Linux ppl realized this and implemented MAP_POPULATE but once you're doing that you might as well just eagerly populate the normal way. Mmap() can be a convenient interface when you aren't latency sensitive but otherwise it's not appropriate.
- vardump 10y ago
  You're right that mmap is not free. It's just a lot better than current status quo. Loading more or less full scene assets to GPU RAM regardless whether they're actually present in current frame or not. Even if some texture is visible, it might be only a tiny fraction of some particular mipmap level is actually needed. TLB flush cost is pretty insignificant here. A bit like accidentally crushing your finger with a sledgehammer and complaining the hammer was a bit cold. Besides, you'd be talking about TLB flush cost on the GPU. Maybe GPUs can just hide all of that latency with a high number of hardware threads, just like they've hidden RAM latency for over 10 years.
  - saynsedit 10y ago
    Mmap() is not the only obvious solution for unused assets. There are other ways with more explicit operational specs. If you design the solution for this problem from first principles, you'll come up with something more appropriate than mmap()
    - vardump 10y ago
      That's a very meta comment. Sure you can figure out if a texture is used in the current visible set (like in a certain part of a game level). But then it starts to get tricky! Any concrete ideas how to determine which parts (= memory pages) of a texture are actually needed to draw the scene? If you don't know, you're going to waste a lot of I/O and memory capacity for something you don't need in the first place. Remember a texture... : 1) ... has multiple mipmap [1] levels. Say you have 1024x1024 texture. You'll also need 512x512, 256x256, 128x128... etc versions. Depending on the triangle orientation [2], GPU might need some spatial areas (not all!) from any of those levels. 1024x1024 for the corner that's near camera and 128x128 for the faraway portion. 2) ... has spatial data order. It's not in row-major order (think scanlines), but in some space filling curve order (like Z-order curve [3]). This helps caching AND paging schemes -- other accesses are spatial and very likely to be nearby memory addresses in the texture. 3) ... is rarely drawn alone. There are often multiple objects using same texture. Sometimes that's true even if actual visible portion is completely different, like texture atlases [4]. This makes it non-trivial to consider points 1 and 2. 4) ... is sometimes huge. Uncompressed 4096x4096 float32 RGBA texture takes 256 MB (4096 * 4096 * 4 * 4) memory just for the first mipmap level. All (traditional "pyramid" type) mipmap levels together would take about 341 MB. So how are you going to determine which memory ranges of the texture really need to be in the memory? [1]: https://en.wikipedia.org/wiki/Mipmap https://en.wikipedia.org/wiki/Mipmap [2]: https://en.wikipedia.org/wiki/Anisotropic_filtering https://en.wikipedia.org/wiki/Anisotropic_filtering [3]: https://en.wikipedia.org/wiki/Z-order_curve https://en.wikipedia.org/wiki/Z-order_curve [4]: https://en.wikipedia.org/wiki/Texture_atlas https://en.wikipedia.org/wiki/Texture_atlas
zamalek 10y ago
> can handle RAM swapping from disk Slight caveat, Windows 10 rarely pages out to the disk.[1] I'm not sure if it's possible to ask it to treat your mmaps in this way. Regardless, implementing the synchronization required to pull this off would be a nightmare - especially in Vulkan/DX12. The OS would also need some form of API where you are notified that a mmaped page is faulting. Except for the very top studios (AAA) it would likely be a completely unapproachable API. Still, it would be fascinating to see what the very best could do with it. > You can only load 33MB of assets in a one frame in a best-case scenario. Carmack indicates that "you could still manually pre-touch media to guarantee residence". Meaning that we're back to loading screens (hopefully shorter ones, though). [1]: https://channel9.msdn.com/Blogs/Seth-Juarez/Memory-Compression-in-Windows-10-RTM https://channel9.msdn.com/Blogs/Seth-Juarez/Memory-Compressi...
taspeotis 10y ago
> You can only load 33MB of assets in a one frame in a best-case scenario. Back the GPU mapped resources with RAM. I have 16GB of it. That's plenty for one level's worth of assets. GPU <=> RAM <=> SSD.
- johncolanduoni 10y ago
  I suspect we'll see more of this as 16+GB of RAM becomes more standard, at least for gamers. In the past it just wasn't a case that was worth optimizing for.
  - imtringued 10y ago
    Why does RAM even matter? Warframe merely needs 700MB and yet it still looks great.
    - douche 10y ago
      I would really like it if some games would take advantage of the gigs of RAM I have just sitting around unused. Why are you thrashing disk loading assets all the time, when there's 12 GB of pristine, untouched RAM available? Obviously, there's the x86/x64 divide there - hopefully nobody is buying new 32-bit systems anymore, and that limitation can go away - although I'd rather get a x64 version of Visual Studio, but apparently that's not a good idea, because reasons[1] [1] https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere/ https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting...
      - dkersten 10y ago
        Similarly, I wish games would be smarter about level loading. One game I recently played, a racing game, when you select "restart race" it reloads the entire level (3d models, textures etc) when really all it had to do was reset a handful of variable (car positions, time, a few other things like that). If its not possible to reset these variables, then take a snapshot! Its especially annoying when a game, eg, autosaves before a boss battle and then when you die, instead of just resetting some stats and inventory, you have to reload everything... They already know there's a good chance you will die (that's why they autosave!). If its too much effort to reload just the bits that need it, then take a snapshot of non-graphics memory at the autosave point and just reload that. There's too many games out now where you can die very quickly (within seconds) if you're not that good yet, and then have to sit through a multi-minute loading phase over and over... very frustrating. (obviously this applies only to "reloading", not terminating the game and loading)
deleted 10y ago
[deleted]
hvidgaard 10y ago
Unless I'm understanding things the wrong way, he isn't saying it should be the only way, just the standard way. The majority of applications are not performance sensitive, and mmap will be simpler and probably save ressources (by leaving untouched assets on the disk). If profiling show you're limited by pagefaults, then preloading by simply touching the memory will have it ready. It simplifies things, which is almost always a good thing.
vardump 10y ago
> If a frame is 16ms, and the best consumer SSDs are around 2GB/s, You can only load 33MB of assets in a one frame in a best-case scenario. I think page faulting can work a lot better for graphics assets (= textures) than for general purpose computing, because the system has special knowledge about data and can avoid processing pauses by (temporarily) using lower fidelity mipmap levels. 1) All of those assets aren't present in the current frame. 33 MB might cover the whole scene anyways. 2) Texture aware page fault mechanism can transfer low lower detail mipmap levels first. Two detail levels lower mipmap is just 1/16th of data, but is still going to be good enough for those few tens of milliseconds until better LoD can be loaded. 3) So in 3 frames (5ms) you have 100 MB. This probably covers current scene pretty well. So everything will just appear to be there. Eyes won't have time to focus in time it takes to load all full quality assets for current scene, even if your SSD can load just 500 MB/s. Remember, with page fault mechanism you don't need to load all assets, just those that are actually visible in the current scene. So initially there's less data to transfer.
- creshal 10y ago
  Aren't textures loaded into memory compressed anyway? Even 33MB is a lot of data when compressed properly.
  - vardump 10y ago
    Yes. But it doesn't change anything. Lower LoD mipmap level is going to be less data with or without compression. Each lower level data size is just 25% of previous.
exDM69 10y ago
> If a frame is 16ms, and the best consumer SSDs are around 2GB/s, You can only load 33MB of assets in a one frame in a best-case scenario. 33 MB of assets per frame is more than enough for a lot of practical tasks. Modern texture compression achieves 2 bits per pixel (e.g. ASTC 8x8) with very little percievable loss of quality (when you apply texture mapping, lighting, effects, etc. ASTC 12x12 gets 0.89 bits per pixel, but noticeable loss of quality). At this rate, the 33 MB/frame is 16k x 8k worth of texture data, every frame. Vastly more than there are pixels on screen. And this figure does not take into account the block cache at all. If the data has been used recently (several minutes depending on RAM size), a copy of it might be still around in RAM which would make it nearly instantaneous and almost a gigabyte per frame of data (assuming all memory bw is put to this use). As for the framerate issues, it would be imperative that this technique is implemented in a stall-free way (which is possible with Vulkan/D3D12) so that a steady 60 fps is maintained. All textures should have at least a few mip map levels resident at all times to fall back on. A single "standard" GPU sparse page (64k) is 512x512 texels at ASTC 8x8, which is quite a large texture already. In other words: 33 MB per frame is a lot more than what we get today.
- dogma1138 10y ago
  The GPU doesn't have DMA to the disk or RAM it has to go through the CPU to access it which causes quite a delay. Even if you read from RAM during normal operations you'll have very low framerate unless you are using pretty damn good latency masking a good example will be texture streaming where you hold low res textures in your GPU memory and load the higher res ones from RAM or disk and even on very high end systems it causes allot of texture popins which people find rather annoying.
  - vardump 10y ago
    GPU can just queue page faults and raise an IRQ. Those faults can then be handled in any size of group on the CPU side. By using a queue, latency can be effectively hidden. Perhaps disk I/O DMA can even be directly connected to GPU DMA, bypassing system RAM entirely. Even currently, ethernet and disk DMA can bypass memory and go directly to CPU L3 cache. With existing flexibility like that, it's not far-fetched to be able to connect DMA between two devices. Pretty much same happens when you touch a page that's not present from user mode. CPU will get interrupted and queue disk I/O to get the faulting page. Even disks themselves have their internal queues (like SATA NCQ). Disks also have CPUs to serve queued I/O requests.
amelius 10y ago
This is only a concern for "videophiles", who insist that the 60fps are always guaranteed.
- astrange 10y ago
  Which is tricky, actually, because real video can come in 24fps or 59.94fps (60/1.001). Your TV can handle this but your computer monitor can't, so you lose frames all the time.
CyberDildonics 10y ago
At 2560x1600 8 bit color a full frame uncompressed is only 12MB. 2560 * 1600 * 3 = 12,288,000 bytes.
- vardump 10y ago
  That's assuming a lot. 1) Hardware doesn't usually support 3 byte pixels. Pretty safe to assume at least 32bpp pixels, 4 bytes per pixel. 2) Hardware might only support power-of-two line pitches (width, number of bytes between screen pixel rows). Horizontal resolution would still be 2560, remaining pixels would just be hidden. That way hardware can always rely on bit shifting when computing display addresses and possibly other tricks. 3) Frame buffer might not even be in row-major format in the first place. So 2560 * 1600 32bpp might just as well be 4096 * 1600 * 4 = 25 MB. Or something else.

hartror 10y ago

I suspect if anyone had thought through this it would be John Carmack. His game design skills can be called into question. His 3D engine skills are second to none[1]. [1] As an individual. I suspect why we haven't see as much from him since Quake 3 is that his skills don't scale to a team.

ralfd 10y ago
> I suspect why we haven't see as much from him since Quake 3 is that his skills don't scale to a team. He did other stuff like rocket design and all that VR/Oculus Gear stuff
joakleaf 10y ago
> I suspect why we haven't see as much from him since Quake 3 Not quite accurate. Since Quake 3 he made Unified lighting and shadowing (for Doom 3) and Megatextures (for Quake 5 and Rage). I can't really think of any other major paradigm shifts over the last 10-15 in game graphics engines. There are lots of little improvements everywhere, but they seem more evolutionary than the revolutionary steps we saw in the 90s (textureMapping, raycasting, BSPs, PVS, lightmaps, Sorted edge rasterization, bilinear filtering, bezier-surferaces, shaders, unified lighting/shadowing and beam trees, etc.).
- NTripleOne 10y ago
  Let's be honest though, did anyone actually like megatextures? From the consumer's point of view, all they ever did was have bad AMD compatibility and streaming issues on every platform.
  - MLR 10y ago
    I think for Rage it was an idea ahead of its time, but they're still used in the new Doom which doesn't seem to have the same issues and has been praised for good optmisation.
    - Zardoz84 10y ago
      I saw these technique on the original Unreal Tournament.
      - Aeolos 10y ago
        The original Unreal Tournament was not using megatextures. There was simply no hardware support for that.
    - jsheard 10y ago
      I believe the new Doom still uses virtual textures to an extent, but they seem to have given up on the idea of using it to apply unique texture assets to every surface in the game as they did in Rage. Without globally unique textures Megatexture goes from a paradigm shift to just an implementation detail, unfortunately.
  - SCdF 10y ago
    Rage was gorgeous. The game was terrible, but it was incredibly pretty, mostly because of megatextures. Some pundit (TotalBiscuit?) referred to it looking like a moving painting, and in places it really was that breathtaking. Again, the game was unfortunately a few fun sections interspersed with really un fun things, but that has nothing to do with the tech. (FWIW I ran it on AMD and it had major problems, and then a year or so later it was perfect. AFAICT they patched most of the issues away on PC)

saynsedit 10y ago

I was facepalming too while reading this. I'd expect Carmack to understand the ugly truth behind mmap: it's not free. It's more than not free, demand-paging actually adds significant cost: TLB flushes aren't performance friendly. Linux ppl realized this and implemented MAP_POPULATE but once you're doing that you might as well just eagerly populate the normal way. Mmap() can be a convenient interface when you aren't latency sensitive but otherwise it's not appropriate.

vardump 10y ago
You're right that mmap is not free. It's just a lot better than current status quo. Loading more or less full scene assets to GPU RAM regardless whether they're actually present in current frame or not. Even if some texture is visible, it might be only a tiny fraction of some particular mipmap level is actually needed. TLB flush cost is pretty insignificant here. A bit like accidentally crushing your finger with a sledgehammer and complaining the hammer was a bit cold. Besides, you'd be talking about TLB flush cost on the GPU. Maybe GPUs can just hide all of that latency with a high number of hardware threads, just like they've hidden RAM latency for over 10 years.
- saynsedit 10y ago
  Mmap() is not the only obvious solution for unused assets. There are other ways with more explicit operational specs. If you design the solution for this problem from first principles, you'll come up with something more appropriate than mmap()
  - vardump 10y ago
    That's a very meta comment. Sure you can figure out if a texture is used in the current visible set (like in a certain part of a game level). But then it starts to get tricky! Any concrete ideas how to determine which parts (= memory pages) of a texture are actually needed to draw the scene? If you don't know, you're going to waste a lot of I/O and memory capacity for something you don't need in the first place. Remember a texture... : 1) ... has multiple mipmap [1] levels. Say you have 1024x1024 texture. You'll also need 512x512, 256x256, 128x128... etc versions. Depending on the triangle orientation [2], GPU might need some spatial areas (not all!) from any of those levels. 1024x1024 for the corner that's near camera and 128x128 for the faraway portion. 2) ... has spatial data order. It's not in row-major order (think scanlines), but in some space filling curve order (like Z-order curve [3]). This helps caching AND paging schemes -- other accesses are spatial and very likely to be nearby memory addresses in the texture. 3) ... is rarely drawn alone. There are often multiple objects using same texture. Sometimes that's true even if actual visible portion is completely different, like texture atlases [4]. This makes it non-trivial to consider points 1 and 2. 4) ... is sometimes huge. Uncompressed 4096x4096 float32 RGBA texture takes 256 MB (4096 * 4096 * 4 * 4) memory just for the first mipmap level. All (traditional "pyramid" type) mipmap levels together would take about 341 MB. So how are you going to determine which memory ranges of the texture really need to be in the memory? [1]: https://en.wikipedia.org/wiki/Mipmap https://en.wikipedia.org/wiki/Mipmap [2]: https://en.wikipedia.org/wiki/Anisotropic_filtering https://en.wikipedia.org/wiki/Anisotropic_filtering [3]: https://en.wikipedia.org/wiki/Z-order_curve https://en.wikipedia.org/wiki/Z-order_curve [4]: https://en.wikipedia.org/wiki/Texture_atlas https://en.wikipedia.org/wiki/Texture_atlas

zamalek 10y ago

> can handle RAM swapping from disk Slight caveat, Windows 10 rarely pages out to the disk.[1] I'm not sure if it's possible to ask it to treat your mmaps in this way. Regardless, implementing the synchronization required to pull this off would be a nightmare - especially in Vulkan/DX12. The OS would also need some form of API where you are notified that a mmaped page is faulting. Except for the very top studios (AAA) it would likely be a completely unapproachable API. Still, it would be fascinating to see what the very best could do with it. > You can only load 33MB of assets in a one frame in a best-case scenario. Carmack indicates that "you could still manually pre-touch media to guarantee residence". Meaning that we're back to loading screens (hopefully shorter ones, though). [1]: https://channel9.msdn.com/Blogs/Seth-Juarez/Memory-Compression-in-Windows-10-RTM https://channel9.msdn.com/Blogs/Seth-Juarez/Memory-Compressi...

taspeotis 10y ago

> You can only load 33MB of assets in a one frame in a best-case scenario. Back the GPU mapped resources with RAM. I have 16GB of it. That's plenty for one level's worth of assets. GPU <=> RAM <=> SSD.

johncolanduoni 10y ago
I suspect we'll see more of this as 16+GB of RAM becomes more standard, at least for gamers. In the past it just wasn't a case that was worth optimizing for.
- imtringued 10y ago
  Why does RAM even matter? Warframe merely needs 700MB and yet it still looks great.
  - douche 10y ago
    I would really like it if some games would take advantage of the gigs of RAM I have just sitting around unused. Why are you thrashing disk loading assets all the time, when there's 12 GB of pristine, untouched RAM available? Obviously, there's the x86/x64 divide there - hopefully nobody is buying new 32-bit systems anymore, and that limitation can go away - although I'd rather get a x64 version of Visual Studio, but apparently that's not a good idea, because reasons[1] [1] https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere/ https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting...
    - dkersten 10y ago
      Similarly, I wish games would be smarter about level loading. One game I recently played, a racing game, when you select "restart race" it reloads the entire level (3d models, textures etc) when really all it had to do was reset a handful of variable (car positions, time, a few other things like that). If its not possible to reset these variables, then take a snapshot! Its especially annoying when a game, eg, autosaves before a boss battle and then when you die, instead of just resetting some stats and inventory, you have to reload everything... They already know there's a good chance you will die (that's why they autosave!). If its too much effort to reload just the bits that need it, then take a snapshot of non-graphics memory at the autosave point and just reload that. There's too many games out now where you can die very quickly (within seconds) if you're not that good yet, and then have to sit through a multi-minute loading phase over and over... very frustrating. (obviously this applies only to "reloading", not terminating the game and loading)

deleted 10y ago

[deleted]

hvidgaard 10y ago

Unless I'm understanding things the wrong way, he isn't saying it should be the only way, just the standard way. The majority of applications are not performance sensitive, and mmap will be simpler and probably save ressources (by leaving untouched assets on the disk). If profiling show you're limited by pagefaults, then preloading by simply touching the memory will have it ready. It simplifies things, which is almost always a good thing.

vardump 10y ago

> If a frame is 16ms, and the best consumer SSDs are around 2GB/s, You can only load 33MB of assets in a one frame in a best-case scenario. I think page faulting can work a lot better for graphics assets (= textures) than for general purpose computing, because the system has special knowledge about data and can avoid processing pauses by (temporarily) using lower fidelity mipmap levels. 1) All of those assets aren't present in the current frame. 33 MB might cover the whole scene anyways. 2) Texture aware page fault mechanism can transfer low lower detail mipmap levels first. Two detail levels lower mipmap is just 1/16th of data, but is still going to be good enough for those few tens of milliseconds until better LoD can be loaded. 3) So in 3 frames (5ms) you have 100 MB. This probably covers current scene pretty well. So everything will just appear to be there. Eyes won't have time to focus in time it takes to load all full quality assets for current scene, even if your SSD can load just 500 MB/s. Remember, with page fault mechanism you don't need to load all assets, just those that are actually visible in the current scene. So initially there's less data to transfer.

creshal 10y ago
Aren't textures loaded into memory compressed anyway? Even 33MB is a lot of data when compressed properly.
- vardump 10y ago
  Yes. But it doesn't change anything. Lower LoD mipmap level is going to be less data with or without compression. Each lower level data size is just 25% of previous.

exDM69 10y ago

> If a frame is 16ms, and the best consumer SSDs are around 2GB/s, You can only load 33MB of assets in a one frame in a best-case scenario. 33 MB of assets per frame is more than enough for a lot of practical tasks. Modern texture compression achieves 2 bits per pixel (e.g. ASTC 8x8) with very little percievable loss of quality (when you apply texture mapping, lighting, effects, etc. ASTC 12x12 gets 0.89 bits per pixel, but noticeable loss of quality). At this rate, the 33 MB/frame is 16k x 8k worth of texture data, every frame. Vastly more than there are pixels on screen. And this figure does not take into account the block cache at all. If the data has been used recently (several minutes depending on RAM size), a copy of it might be still around in RAM which would make it nearly instantaneous and almost a gigabyte per frame of data (assuming all memory bw is put to this use). As for the framerate issues, it would be imperative that this technique is implemented in a stall-free way (which is possible with Vulkan/D3D12) so that a steady 60 fps is maintained. All textures should have at least a few mip map levels resident at all times to fall back on. A single "standard" GPU sparse page (64k) is 512x512 texels at ASTC 8x8, which is quite a large texture already. In other words: 33 MB per frame is a lot more than what we get today.

dogma1138 10y ago
The GPU doesn't have DMA to the disk or RAM it has to go through the CPU to access it which causes quite a delay. Even if you read from RAM during normal operations you'll have very low framerate unless you are using pretty damn good latency masking a good example will be texture streaming where you hold low res textures in your GPU memory and load the higher res ones from RAM or disk and even on very high end systems it causes allot of texture popins which people find rather annoying.
- vardump 10y ago
  GPU can just queue page faults and raise an IRQ. Those faults can then be handled in any size of group on the CPU side. By using a queue, latency can be effectively hidden. Perhaps disk I/O DMA can even be directly connected to GPU DMA, bypassing system RAM entirely. Even currently, ethernet and disk DMA can bypass memory and go directly to CPU L3 cache. With existing flexibility like that, it's not far-fetched to be able to connect DMA between two devices. Pretty much same happens when you touch a page that's not present from user mode. CPU will get interrupted and queue disk I/O to get the faulting page. Even disks themselves have their internal queues (like SATA NCQ). Disks also have CPUs to serve queued I/O requests.

amelius 10y ago

This is only a concern for "videophiles", who insist that the 60fps are always guaranteed.

astrange 10y ago
Which is tricky, actually, because real video can come in 24fps or 59.94fps (60/1.001). Your TV can handle this but your computer monitor can't, so you lose frames all the time.

CyberDildonics 10y ago

At 2560x1600 8 bit color a full frame uncompressed is only 12MB. 2560 * 1600 * 3 = 12,288,000 bytes.

vardump 10y ago
That's assuming a lot. 1) Hardware doesn't usually support 3 byte pixels. Pretty safe to assume at least 32bpp pixels, 4 bytes per pixel. 2) Hardware might only support power-of-two line pitches (width, number of bytes between screen pixel rows). Horizontal resolution would still be 2560, remaining pixels would just be hidden. That way hardware can always rely on bit shifting when computing display addresses and possibly other tricks. 3) Frame buffer might not even be in row-major format in the first place. So 2560 * 1600 32bpp might just as well be 4096 * 1600 * 4 = 25 MB. Or something else.