3 ms·

Most of the comments in here seem to be missing the most important aspect. This is open source: https://github.com/chellmuth/gpu-motunui/ https://github.com/ch

Most of the comments in here seem to be missing the most important aspect. This is open source: https://github.com/chellmuth/gpu-motunui/ https://github.com/chellmuth/gpu-motunui/ Let me explain. GPU rendering of cinema quality scenes by itself is not that new. V-Ray GPU was around in 2013 and already had an impressive showreel back then: https://www.youtube.com/watch?v=RYPFY5OUzdk https://www.youtube.com/watch?v=RYPFY5OUzdk I'd count Octane and Redshift as the next big contenders, who together with V-Ray switching from perpetual to subscription pricing, took over the market. Here's an example of a Redshift render from 2016: https://www.youtube.com/watch?v=to8yh83jlXg https://www.youtube.com/watch?v=to8yh83jlXg Lately, Pixar has been handing out Renderman GPU betas, which has already been used in the new jungle book movie: https://youtu.be/tiWr5aqDeck?t=171 https://youtu.be/tiWr5aqDeck?t=171 Along with this development, the price has gone down. From $1200 per V-Ray license, to $600 per Redshift license and now it seems like the previously prohibitively expensive Pixar renderer will soon be offered for $500. And recently, people have been using Houdini ($6000 per seat) to export their scenes as USD (free open file format) so that they can use Blender 2.81 for rendering (also free). But the conversion to get things into Blender is work. This renderer can use the Disney production data directly, which is very convenient if you want to drop it in at the last minute for cost saving. GPU rendering has gone from novelty in 2013 to established in 2016 to become the new default in 2018/2019. And this released as open source to me implies that the commercial renderer market will soon be dead. It looks "good enough" for advertisements and archviz, which is where the money is made.

alkonaut 6y ago
What is the performance difference between state of the art CPU vs. GPU? e.g. Embree vs. OptiX?
- 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.
- fxtentacle 6y ago
  In my experience, rendering a natural landscape with clouds, trees, and grass in 4K resolution took about 40 hours on CPU (Ryzen 2700x) while it took about 1 hour on GPU (1080 TI). It could have been even faster on GPU, but the scene was 70GB of geometry and textures, so the GPU spent some time swapping with main memory.

alkonaut 6y ago

What is the performance difference between state of the art CPU vs. GPU? e.g. Embree vs. OptiX?

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.
fxtentacle 6y ago
In my experience, rendering a natural landscape with clouds, trees, and grass in 4K resolution took about 40 hours on CPU (Ryzen 2700x) while it took about 1 hour on GPU (1080 TI). It could have been even faster on GPU, but the scene was 70GB of geometry and textures, so the GPU spent some time swapping with main memory.