3 ms·

For ideal scenes that fit completely in GPU memory and use hardware meshes and hardware texture filtering and GPU shading, rendering on a GPU is often in the ra

by dahart 6y ago

For ideal scenes that fit completely in GPU memory and use hardware meshes and hardware texture filtering and GPU shading, rendering on a GPU is often in the range of 10x to 100x faster than CPU (as reported by the people writing production renderers today). Since production scenes are commonly larger than GPU ram and even CPU ram too, it complicates things. Embree is a renderer and OptiX isn’t, so they can’t be directly compared, but I think it’s fair to say that OptiX based renderers are typically significantly faster for ideal scenes that fit in memory and use hardware supported primitives, while there are cases where Embree has some huge advantages, like scenes that don’t fit in memory, and Embree has oriented bounding boxes that can make some kinds of scene geometry render much faster.

boulos 6y ago
Dave, I’m curious to see what happens now that the latest Quadro and Tesla parts have 40 or 48 GB of memory. That’s now plenty enough for all the geometry of a production scene plus a texture cache, but almost never enough for the base textures themselves. I like the “use the cpu to do texture lookups while the gpu is tracing shadow rays” solution here. But I thought you or Keith had done a similar out-of-core with texture caching implementation for inclusion directly into OptiX. My assumption is that once you got the texture cache full enough, stalling on a Unified Memory page fault or similar wouldn’t be super common (again, depends on the hit rate). Does the new cuMemAddressReserve combined with mmap on the host side let you have a giant virtual mmap’ed host side memory region?
- dahart 6y ago
  Yeah, exactly right Simon. The memory is now getting big enough for production geometry, but we still need out of core texture support. We are shipping some (open source) out of core texture loading with OptiX now, lead by Mark Leone. Definitely yes, the idea is that after a few re-launches you’ll have all the mipmap texture tiles you need resident and you can render many samples without a stall. To be honest I’m not sure whether we’re using mmap for this. (I’ve had my head buried in curves.) Mark is calling the high level concept “cooperative paging”, meaning the GPU and CPU work together to handle page faults and fill new load requests. The user can decide / define what the page fault behavior is, and whether & how they might want to fill the requests. They’re currently working on cache eviction, which will be a big leap when it arrives. This basic technique could be used in Chris’ Motunui to fill geometry as well - you could use standin boxes for the instances and a ray hit would fault & load the internal geometry. So, obviously, that’s pretty complicated and not necessarily guaranteed to fit in memory, but when it worked it could save a ton of time. I’m thinking about ways to blend what Chris did with something like this to try and get the advantages of both.

by dahart 6y ago

boulos 6y ago

Dave, I’m curious to see what happens now that the latest Quadro and Tesla parts have 40 or 48 GB of memory. That’s now plenty enough for all the geometry of a production scene plus a texture cache, but almost never enough for the base textures themselves. I like the “use the cpu to do texture lookups while the gpu is tracing shadow rays” solution here. But I thought you or Keith had done a similar out-of-core with texture caching implementation for inclusion directly into OptiX. My assumption is that once you got the texture cache full enough, stalling on a Unified Memory page fault or similar wouldn’t be super common (again, depends on the hit rate). Does the new cuMemAddressReserve combined with mmap on the host side let you have a giant virtual mmap’ed host side memory region?

dahart 6y ago
Yeah, exactly right Simon. The memory is now getting big enough for production geometry, but we still need out of core texture support. We are shipping some (open source) out of core texture loading with OptiX now, lead by Mark Leone. Definitely yes, the idea is that after a few re-launches you’ll have all the mipmap texture tiles you need resident and you can render many samples without a stall. To be honest I’m not sure whether we’re using mmap for this. (I’ve had my head buried in curves.) Mark is calling the high level concept “cooperative paging”, meaning the GPU and CPU work together to handle page faults and fill new load requests. The user can decide / define what the page fault behavior is, and whether & how they might want to fill the requests. They’re currently working on cache eviction, which will be a big leap when it arrives. This basic technique could be used in Chris’ Motunui to fill geometry as well - you could use standin boxes for the instances and a ray hit would fault & load the internal geometry. So, obviously, that’s pretty complicated and not necessarily guaranteed to fit in memory, but when it worked it could save a ton of time. I’m thinking about ways to blend what Chris did with something like this to try and get the advantages of both.