8 ms·

> What I did say is that GPU porting of offline renderers is a waste of time better spent otherwise. Not true. You can get speedups of 10x-100x by moving to th

by dahart 7y ago

> What I did say is that GPU porting of offline renderers is a waste of time better spent otherwise. Not true. You can get speedups of 10x-100x by moving to the GPU. There is no known alternative way to spend your time to achieve the same outcome with the same effort. Using ideal (unachievable) perfect importance sampling algorithms might give you 2x, in some cases, if you're lucky. What is making you think that people aren't improving their rendering algos or renderers, or that GPUs are preventing other improvements? > And that denoising is solving a problem you would have less off if you didn't waste time with the former. And that 3Delight is proof of that. Not true. You can't get rid of the need for denoising when using Monte Carlo path tracing techniques, and 3Delight's geo light sampling does not in any way demonstrate that you can.

fxtentacle 7y ago
You get those 10x speedups only if stuff fits into GPU RAM. For movie cgi, that is usually not the case, meaning no GPU speedup.
- dahart 7y ago
  That is currently changing with on-demand loading, streaming, and NVME technologies, larger GPU ram, and multi-GPU systems.
  - virtualritz 7y ago
    We are speculating here now. I though this discussion was about the status quo; not what we imagine soon to be. Even if the bandwidth bottleneck gets solved in the future ... scenes from movie sets usually are big enough so transformations are stored as double precision matrices to avoid objects starting to jitter when they are far away from the origin. Have you checked double precision GFLOPs on you favorite GPUs lately? And then compared those and their prices to some Ryzen 3970X CPU specs and their prices?
    - dahart 7y ago
      You're wasting your own money if you buy a CPU based on fp64 flops and then start using any of the renderers you've cited so far.
      - virtualritz 7y ago
        Yeah, right. Numbers?
        dahart 7y ago
        Which renderers use fp64?
        virtualritz 7y ago
        All of them. Just for example in the PRMan 3.9 release notes from 2001, it says under 'Miscellaneous Changes': "Some parts of the renderer now use double-precision floating point arithmetic, to avoid round-off error."[1] Your model-to-camera to camera matrix needs to be only single precision, usually. But your model-to-world matrix needs to be double precision to avoid jittering. So to calculate the former you use double precision and then you can truncate the resulting matrix to single precision for use e.g. in shaders. Everything dandy by then, even for GPUs. But first you need to get there somehow. So if you have a gazillion instances in your scene, particles, blades of grass, leaves of tress, spaceships, whatever, you need a gazillion matrix multiplications with double precision to build your acceleration structure and to actually start generating pixels. It's one of many reasons why GPU based renderers performance goes to shit, particularly on time to first pixel, when scenes of such complexity get thrown at them. Contemporary GPUs have comparatively shitty f64 performance. Edit: added example PRMan changelog backing up the claim in the 1st sentence. This was most likely considering just xforms. For ray-tracing specific issues and f64 see e.g. the PBR book on solutions to ray intersection precision challenges. [1] https://renderman.pixar.com/resources/RenderMan_20/rnotes-3.9.html#misc https://renderman.pixar.com/resources/RenderMan_20/rnotes-3....
virtualritz 7y ago
> Not true. You can get speedups of 10x-100x by moving to the GPU. [...] Ok, I take you by your word. Mind you, all the points I made were about offline rendering. I dare you to put your money where your mouth is. Disney's Moana Set[1] it a good, publicly available example. Show me how you get a 10× speed up using a GPU over 3Delight[2] with any commercial renderer out there. Really. I look forward to it. Note that I do not take you up on your 100× because it will satisfy me to see a 10× speedup to accept your point. By far. Price of GPU and CPU rig need to be comparable. Electricity cost must be factored in too so if your render costs twice as much, rig plus running costs, you divide your results by that factor. And vice versa. And as for your RIB comment earlier: don't worry -- we will add the scene parsing time to the finals; as we should. Total time will be from render command issued to final image being available on disk. And while this is an outdated example the scene complexity reflects what users of Houdini, even single artist types, are throwing at renderers nowadays. Or trying to. > What is making you think that people aren't improving their rendering algos or renderers [...] Uhhm, experience? I have been using offline renderers in production since 1994. And I see the rate of progress in commercial offline renderers drop in correlation with those people spending more effort on porting their stuff to GPUs. Sure, could be a coincidence and no causality at all. Maybe there are better explanations -- I'm all ears. > Not true. You can't get rid of the need for denoising when using Monte Carlo path tracing techniques [...] Says who? I would never make such a claim either way. So before you mis-quote me again: I ever said you can get rid of the need for denoising and I never said you cannot get rid of the need for denoising for Monte Carlo path tracing. In fact I never even mentioned Monte Carlo path tracing. Now going back to what I actually wrote: maybe re-read that. Notice the word I put in Italics so it was harder to miss? Just for the record: you are mis-quoting me for the fourth time in this thread. [1] https://www.technology.disneyanimation.com/islandscene https://www.technology.disneyanimation.com/islandscene [2] Just an indication (white bars only) since this misses data on electricity costs and parsing time (I think, but I will verify with them): https://documentation.3delightcloud.com/display/3DLC/Cloud+Rendering+Speed https://documentation.3delightcloud.com/display/3DLC/Cloud+R...
- dahart 7y ago
  > I never said you cannot get rid of the need for denoising for Monte Carlo path tracing. You claimed that investing in sampling algorithms would reduce the need for denoising. You claimed that 3Delight's sampling algorithm is proof of that. I disagree, I think denoising gives the same benefit to 3Delight as it does to Arnold & RenderMan, which is reduced time to a noise-free preview. > In fact I never even mentioned Monte Carlo path tracing. I don't even know what you mean by this, if we're not talking about Monte Carlo, why are you commenting on denoisers at all? You posted a link to 3delight's geo light sampling marketing comparison. You know that's a Monte Carlo method, right? > Sure, could be a coincidence and no causality at all. Maybe there are better explanations -- I'm all ears. Yes, that's right, it could be coincidence. Do you follow Siggraph or rendering research, and have you noticed that the rate of progress in CPU rendering algorithms has slowed? Do you have more examples of features that CPU-only renderers have that are surpassing everyone porting to GPU? I've seen only one example in this thread. > you are mis-quoting me for the fourth time in this thread. I don't believe that's true. I may be misunderstanding your points or summarizing you incorrectly or in a way you don't like. I am definitely disagreeing with some of your points and trying to explain why, but I don't believe I have mis-quoted you even once. >> You can't get rid of the need for denoising when using Monte Carlo path tracing techniques [...] > Says who? I would never make such a claim either way. Wikipedia says so, and I'm happy to repeat it. Would you not make that claim because you haven't studied what Monte Carlo is, or because you know of advanced techniques that are noise free? There are no known noise free Monte Carlo rendering techniques except for on trivial and/or hypothetical scenes. The kind of scenes you're talking about always have randomness (noise), because the very name "Monte Carlo" is referring to random sampling. I'm happy to explain more about why Monte Carlo comes with noise, in case it's not clear, or why denoisers will always be valuable in the context of Monte Carlo rendering methods...

by dahart 7y ago

fxtentacle 7y ago

You get those 10x speedups only if stuff fits into GPU RAM. For movie cgi, that is usually not the case, meaning no GPU speedup.

dahart 7y ago
That is currently changing with on-demand loading, streaming, and NVME technologies, larger GPU ram, and multi-GPU systems.
- virtualritz 7y ago
  We are speculating here now. I though this discussion was about the status quo; not what we imagine soon to be. Even if the bandwidth bottleneck gets solved in the future ... scenes from movie sets usually are big enough so transformations are stored as double precision matrices to avoid objects starting to jitter when they are far away from the origin. Have you checked double precision GFLOPs on you favorite GPUs lately? And then compared those and their prices to some Ryzen 3970X CPU specs and their prices?
  - dahart 7y ago
    You're wasting your own money if you buy a CPU based on fp64 flops and then start using any of the renderers you've cited so far.
    - virtualritz 7y ago
      Yeah, right. Numbers?
      - dahart 7y ago
        Which renderers use fp64?
        virtualritz 7y ago
        All of them. Just for example in the PRMan 3.9 release notes from 2001, it says under 'Miscellaneous Changes': "Some parts of the renderer now use double-precision floating point arithmetic, to avoid round-off error."[1] Your model-to-camera to camera matrix needs to be only single precision, usually. But your model-to-world matrix needs to be double precision to avoid jittering. So to calculate the former you use double precision and then you can truncate the resulting matrix to single precision for use e.g. in shaders. Everything dandy by then, even for GPUs. But first you need to get there somehow. So if you have a gazillion instances in your scene, particles, blades of grass, leaves of tress, spaceships, whatever, you need a gazillion matrix multiplications with double precision to build your acceleration structure and to actually start generating pixels. It's one of many reasons why GPU based renderers performance goes to shit, particularly on time to first pixel, when scenes of such complexity get thrown at them. Contemporary GPUs have comparatively shitty f64 performance. Edit: added example PRMan changelog backing up the claim in the 1st sentence. This was most likely considering just xforms. For ray-tracing specific issues and f64 see e.g. the PBR book on solutions to ray intersection precision challenges. [1] https://renderman.pixar.com/resources/RenderMan_20/rnotes-3.9.html#misc https://renderman.pixar.com/resources/RenderMan_20/rnotes-3....

virtualritz 7y ago

> Not true. You can get speedups of 10x-100x by moving to the GPU. [...] Ok, I take you by your word. Mind you, all the points I made were about offline rendering. I dare you to put your money where your mouth is. Disney's Moana Set[1] it a good, publicly available example. Show me how you get a 10× speed up using a GPU over 3Delight[2] with any commercial renderer out there. Really. I look forward to it. Note that I do not take you up on your 100× because it will satisfy me to see a 10× speedup to accept your point. By far. Price of GPU and CPU rig need to be comparable. Electricity cost must be factored in too so if your render costs twice as much, rig plus running costs, you divide your results by that factor. And vice versa. And as for your RIB comment earlier: don't worry -- we will add the scene parsing time to the finals; as we should. Total time will be from render command issued to final image being available on disk. And while this is an outdated example the scene complexity reflects what users of Houdini, even single artist types, are throwing at renderers nowadays. Or trying to. > What is making you think that people aren't improving their rendering algos or renderers [...] Uhhm, experience? I have been using offline renderers in production since 1994. And I see the rate of progress in commercial offline renderers drop in correlation with those people spending more effort on porting their stuff to GPUs. Sure, could be a coincidence and no causality at all. Maybe there are better explanations -- I'm all ears. > Not true. You can't get rid of the need for denoising when using Monte Carlo path tracing techniques [...] Says who? I would never make such a claim either way. So before you mis-quote me again: I ever said you can get rid of the need for denoising and I never said you cannot get rid of the need for denoising for Monte Carlo path tracing. In fact I never even mentioned Monte Carlo path tracing. Now going back to what I actually wrote: maybe re-read that. Notice the word I put in Italics so it was harder to miss? Just for the record: you are mis-quoting me for the fourth time in this thread. [1] https://www.technology.disneyanimation.com/islandscene https://www.technology.disneyanimation.com/islandscene [2] Just an indication (white bars only) since this misses data on electricity costs and parsing time (I think, but I will verify with them): https://documentation.3delightcloud.com/display/3DLC/Cloud+Rendering+Speed https://documentation.3delightcloud.com/display/3DLC/Cloud+R...

dahart 7y ago
> I never said you cannot get rid of the need for denoising for Monte Carlo path tracing. You claimed that investing in sampling algorithms would reduce the need for denoising. You claimed that 3Delight's sampling algorithm is proof of that. I disagree, I think denoising gives the same benefit to 3Delight as it does to Arnold & RenderMan, which is reduced time to a noise-free preview. > In fact I never even mentioned Monte Carlo path tracing. I don't even know what you mean by this, if we're not talking about Monte Carlo, why are you commenting on denoisers at all? You posted a link to 3delight's geo light sampling marketing comparison. You know that's a Monte Carlo method, right? > Sure, could be a coincidence and no causality at all. Maybe there are better explanations -- I'm all ears. Yes, that's right, it could be coincidence. Do you follow Siggraph or rendering research, and have you noticed that the rate of progress in CPU rendering algorithms has slowed? Do you have more examples of features that CPU-only renderers have that are surpassing everyone porting to GPU? I've seen only one example in this thread. > you are mis-quoting me for the fourth time in this thread. I don't believe that's true. I may be misunderstanding your points or summarizing you incorrectly or in a way you don't like. I am definitely disagreeing with some of your points and trying to explain why, but I don't believe I have mis-quoted you even once. >> You can't get rid of the need for denoising when using Monte Carlo path tracing techniques [...] > Says who? I would never make such a claim either way. Wikipedia says so, and I'm happy to repeat it. Would you not make that claim because you haven't studied what Monte Carlo is, or because you know of advanced techniques that are noise free? There are no known noise free Monte Carlo rendering techniques except for on trivial and/or hypothetical scenes. The kind of scenes you're talking about always have randomness (noise), because the very name "Monte Carlo" is referring to random sampling. I'm happy to explain more about why Monte Carlo comes with noise, in case it's not clear, or why denoisers will always be valuable in the context of Monte Carlo rendering methods...