3 ms·
> 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 disa
by virtualritz 6y ago
> 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,
Then we agree to disagree. I can back up all my claims with hard data. Can you?
3Delight's changelog gives you access to all versions of the renderer maybe back to 2006 or so. I think their path tracing core is only after 2016.
So we can download any 'sample', throw the same scene at it and calculate noise properties in the resulting image and see how they got better over time. Be my guest. I know the result and it will back up my claim. Cheers! :)
> You posted a link to 3delight's geo light sampling marketing comparison
Nice 2nd try but not biting. This is not marketing material. 3Delight doesn't employ a single marketing person and this was never published at the time when it was relevant (2017).
> 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...
Thank you for your kind offer, professor, no need. ;)
May I remind you that I said (analogously) that relying on denoisers for improvement is a bad idea not that denoisers are a bad idea per se?
But let's not try diverting this from you being put on the spot to prove your outlandish 10x+ speedup claim, shall we?
Or are you preparing an extra reply to my challenge?
1. GPUs are not faster than CPUs for offline rendering when you factor in costs.
1.1. They are not even faster in the general case when you just go by GFLOPS/US$. You have to look at specific cases to get a speed advantage (exactly my point: you spend R&D on making the general case work within the restrictions of the special case. Example: FP precision).
3. Time spent working around restrictions of GPUs (data transfer, memory size, precision) could be better spent at improving a CPU renderer. Proof: 3Delight.
4. GPUs are not a general alternative to CPU offline rendering because of aforementioned restrictions. That they work in specific cases means the only good reason to invest in R&D supporting them is if your target audience only ever needs to deal with those special cases. No such renderer (claiming to cater only for such audiences) exists. Thus there are no renderers out there which should focus their R&D on GPU or they are simply lying to their customers (and/or themselves).
> Do you follow Siggraph or rendering research, [...]
Yes.
> [...] and have you noticed that the rate of progress in CPU rendering algorithms has slowed?
No.
But I'm curious how you define a "CPU rendering algorithm". I'm all ears.
- dahart 6y ago> I can back up all my claims with hard data. That's where I think you're already off the rails, I don't think this particular point can be proven with hard data, it's about goals. Denoising helps whenever there's noise. 3Delight produces noise with low sample numbers, just like all other renderers. A denoiser will make that faster and enable quicker preview turnarounds. Your argument is that 3Delight's algorithm makes final frame rendering faster, which I'm not arguing with. If it takes longer than 5 seconds to get to final frame, it doesn't matter whether it's faster than others, denoising will provide the same benefit. > I'm curious how you define a "CPU rendering algorithm". I'm all ears. I was really referring to just rendering algorithms in general. There were a lot of papers on how to speed up rendering algorithms in the 80s and 90s, and the speedups were large. A lot fewer in the 2000s and 2010s, and the speedups are no longer multiples, but more often measured in percents. Based on your claims, I'd think you'd have noticed this trend. It's directly related to the rate of progress of features and speed that commercial renderers are releasing. Feel free to provide sources on flops/$ for fp32. (BTW, talking flops/$ ignores RTX.) First Google result disagrees with you https://aiimpacts.org/current-flops-prices/#Graphics_processing_units_GPUs_and_Xeon_Phi_machines https://aiimpacts.org/current-flops-prices/#Graphics_process... Saying that GPUs aren't a general alternative is true but ignoring the trend. They used to be much less of an alternative. They are currently a fast alternative for some workflows, especially preview. They will in the future become more and more of a general alternative.
- virtualritz 6y ago> Feel free to provide sources on flops/$ for fp32. [...] Ok, early morning maths ... been coding for 10 hours but I try: A Quadro 8000 RTX has about 510 f64 GFLOPS and 16,320 f32 GFLOPS according to Wikipedia[1]. It costs US$5,500. A Ryzen 3970X has about 1,320 f64 GFLOPS according to this test[2] and 1,900 f32 GFLOPS. It costs US$2,000 Now a Super Micro board with two EPYC sockets is about US$700 according to Google. So for US$4,700 I get a CPU compute rig with 2,640 f64 GFLOPS. Aka: more than five times as much as the Quadro 8k RTX rig -- at US$800 less. Let's say, we are being unfair and we limit our scene complexity to one that only requires single precision (f32) floating point operations (see my reply above). That's btw one of those "GPU restrictions" renderer developers then try to work around that I talked about earlier. I guess I am trying to say: without going single precision GPUs can not even beat CPUs -- they basically suck. Now with single precision the Quadro 8k RTX is way ahead of the CPU. At 16,310 f32 GFLOPS it is a bit more than four times the compute power of the CPU rig which clocks in at 2×1,900 GFLOPS of f32 precision (mind you just four times, that's why I said if you can even prove a 10x speedup of GPU vs CPU in offline rendering, I take your point). Now looking at actual rendering time ... from launching a render to getting an image on disk .. can the GPU we're looking at ever be four times as fast as the US$700 cheaper CPU rig with this constraint to f32? Absolutely. Most definittly. I would never contest this. Will these constraints satisfy the needs of people doing professional offline rendering today? Definitely not. Shoveling those scenes onto the GPU will rid you of any speed advantage as low as 4x. Let's not even talk about electricity costs. The AMD CPU draws 35W under full load. So that's 70W for two. The Quadro 8k RTX draws 260W. And this is not considering the AC you need to buy, maintain and power feed too cool a farm of these beasts. People who say GPUs will hit it big in offline rendering "soon" are missing important details. And as someone who had to bear with convincing people the other way once in his life already to prevent disaster later on a production I mean this in a very caring way. Lastly: at that time I just talked about everyone was saying GPUs will "soon" play a bigger role. Then over ten years passed. In 2016 two friends of mine, the lead developer of 3Delight and a famous CG researcher who works at NVIDIA were chatting over beers at my house in Berlin. And the latter guy asked the 3Delight dude why they are not investing in GPU research. And the 3Delight dude said: "Because they asked us the same then. And ten years later we're still faster than any GPU renderer out there for the customers we target. And we don't see that changing." Now it's 2020 and it's still spot on. [1] https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#Quadro_RTX_x000_series https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_proces... [2] https://www.pugetsystems.com/labs/hpc/AMD-Threadripper-3970x-Compute-Performance-Linpack-and-NAMD-1631/ https://www.pugetsystems.com/labs/hpc/AMD-Threadripper-3970x...