Iray Starter Scene: Post Your Benchmarks!

1303133353649

Comments

  • AalaAala Posts: 140

    The second image seems to have correct reflections of light in the glass ball. The first one is simply broken.

    Is the caustics enabled in the scene?

    Nope, I checked. Seems to me too that they've fixed some kind of a reflection/refraction bug but I don't see it in the logs, or at least I don't know what I'm looking for.

  • prixatprixat Posts: 1,585

    Wasn't the 'Dual Lobe Specular' new to the Beta? That might cause that diference.

  • AalaAala Posts: 140
    prixat said:

    Wasn't the 'Dual Lobe Specular' new to the Beta? That might cause that diference.

    No, that's in 4.10 too.

  • Used GTX 1080 vs new RTX 2060?

    2060 has way fewer cuda cores but it has tensor stuff.

    Which is a better buy?

  • RayDAntRayDAnt Posts: 1,120
    artphobe said:

    Used GTX 1080 vs new RTX 2060?

    2060 has way fewer cuda cores but it has tensor stuff.

    Which is a better buy?

    Keep in mind, Turing era cuda cores are significantly more powerful than Pascal ones. With that said, 2060s only go up to 6GB of VRAM which imo is pretty low for modern workloads - especially for cg rendering.

  • RayDAntRayDAnt Posts: 1,120
    Aala said:

    Skimming through the log files on the other forum thread about DAZ Studio Beta, I couldn't pinpoint what exactly has changed to cause this.

    Raytracing is an open-ended iterative process in which the key statistics for measuring performance are render time and convergance % - not iterations. Iteration counts are only a useful measure of performance when using the same version of rendering software on different pieces of hardware. DAZ_Rawb's benchmark is convergance limited (unlike, for example, Sickleyields' benchmark which is iteration count limited due to its scene composition.) So judging by the comparison renders and stats you posted for your 1080ti on different versions of DS/Iray with that particular benchmark, the answer to your question seems pretty obvious to me: Iray version 2018.0.1 (the current version in DS beta) has been changed to do a much more comprehensive job of faithfully raytracing an image (reaching a higher convergance % and with greater accuracy) in fewer if computationally more complex iterations than Iray version 2017.0.1 (the current version in DS official.) Ie. it's become better software.

     

    Aala said:

    You're getting much better performance vs 10xx generation cards on 4.11, but those cards render those scenes in 4.10 only about 10-15% slower.

    Don't forget to keep in mind that all current benchmarks for Turing based 20XX cards are only representative of how well they perform at raytracing without utilizing any of their dedicated raytracing hardware. Once APIs like OptiX get updated and rendering engines like Iray (hopefully) adopt full support, we will be able to see what the Turing architecture is truly capable of performance wise for raytracing in comparison to its ancestors like Pascal. Until then, all the 20XX series benchmarks you see posted in places like this thread are gonna be under-reporting reality - and drastically so if NVidia's new gigaray terminology is to be believed.

     

    On a different note, for those still confused/curious about OptiX Prime's current role in DS/Iray as well as why it is slated to not be "getting RTX support" here's some information I've stumbled on recently that you may find interesting:

    Baking shadows or occlusion with OptiX is even simpler: you don't need to define any surface shading, you just want to know if a ray hit something (and possibly what and where it hit, in some cases). For these types of pure geometric queries, we have the OptiX Prime API (Prime, for short). You define the rays and triangles, Prime builds a fast TRBVH acceleration structure [1] then shoots rays against triangles and returns the results to you. That's it. - https://developer.nvidia.com/optix-prime-baking-sample

    Meanwhile, here's the most in-depth technical explanation I've been able to find (so far) for what an RT Core in the Turing architecture actually is and does:

    The RT core essentially adds a dedicated pipeline (ASIC) to the SM to calculate the ray and triangle intersection. It can access the BVH and configure some L0 buffers to reduce the delay of BVH and triangle data access. The request is made by SM. The instruction is issued, and the result is returned to the SM's local register. The interleaved instruction and other arithmetic or memory io instructions can be concurrent. Because it is an ASIC-specific circuit logic, performance/mm2 can be increased by an order of magnitude compared to the use of shader code for intersection calculation.  https://www.reddit.com/r/nvidia/comments/97qogl/former_nvidia_gpu_architect_what_is_rt_core_in/

     So in other words, OptiX Prime isn't "getting RTX support" because RT Cores are OptiX Prime - just in an exponentially higher performing dedicated hardware form.

     

  • LenioTGLenioTG Posts: 2,116
    edited January 2019

    I've rendered the test scene from SY:

    CPU + GPU: 11m and 12s to finish (from Texture Shaded preview, Optix off, memory optimization)

    GPU Only: 32m 22s to finish (from Texture Shaded preview, Optix ON, memory optimization)

    From Iray preview with speed optimization the scene goes over my VRAM.

    My system specs:

    • Ryzen 5 1600
    • GTX 1060 3Gb
    • 4x4Gb 2667Mhz RAM
    • Samsung 970 Evo 250Gb

    I guess I need an upgrade! xD

    What seems strange to me are other benchmarks posted here with a 1060 6Gb, that take 6,5 minutes, but the CUDA difference should be of just 10%!

    Is there a simple list of average benchmarks? It would be really useful to see what GPU to buy, since this thread is too long and contains too many comments other than benchmarks...it would be nice something like "GPU only: 1050 in 15min, 1060 in 10 min, 1070 in 7min, 1080, 2060, 2070, 2080..." etc.

    Post edited by LenioTG on
  • AalaAala Posts: 140
    RayDAnt said:
    Aala said:

    Skimming through the log files on the other forum thread about DAZ Studio Beta, I couldn't pinpoint what exactly has changed to cause this.

    Raytracing is an open-ended iterative process in which the key statistics for measuring performance are render time and convergance % - not iterations. Iteration counts are only a useful measure of performance when using the same version of rendering software on different pieces of hardware. DAZ_Rawb's benchmark is convergance limited (unlike, for example, Sickleyields' benchmark which is iteration count limited due to its scene composition.) So judging by the comparison renders and stats you posted for your 1080ti on different versions of DS/Iray with that particular benchmark, the answer to your question seems pretty obvious to me: Iray version 2018.0.1 (the current version in DS beta) has been changed to do a much more comprehensive job of faithfully raytracing an image (reaching a higher convergance % and with greater accuracy) in fewer if computationally more complex iterations than Iray version 2017.0.1 (the current version in DS official.) Ie. it's become better software.

    I suppose you're right. The 4.11 version of the render looks a bit more converged compared to the 4.10 version even if it has fewer iterations. But I think we need to devise a new scene to understand how exactly it has changed. Two versions of it, where one is time-limited and one is iteration-limited, and then compare the results for both Turing and Pascal cards. That way we can nail down how fast the new generation of cards really is compared to the old.

    RayDAnt said:
    Aala said:

    You're getting much better performance vs 10xx generation cards on 4.11, but those cards render those scenes in 4.10 only about 10-15% slower.

    Don't forget to keep in mind that all current benchmarks for Turing based 20XX cards are only representative of how well they perform at raytracing without utilizing any of their dedicated raytracing hardware. Once APIs like OptiX get updated and rendering engines like Iray (hopefully) adopt full support, we will be able to see what the Turing architecture is truly capable of performance wise for raytracing in comparison to its ancestors like Pascal. Until then, all the 20XX series benchmarks you see posted in places like this thread are gonna be under-reporting reality - and drastically so if NVidia's new gigaray terminology is to be believed.

     

    On a different note, for those still confused/curious about OptiX Prime's current role in DS/Iray as well as why it is slated to not be "getting RTX support" here's some information I've stumbled on recently that you may find interesting:

    Baking shadows or occlusion with OptiX is even simpler: you don't need to define any surface shading, you just want to know if a ray hit something (and possibly what and where it hit, in some cases). For these types of pure geometric queries, we have the OptiX Prime API (Prime, for short). You define the rays and triangles, Prime builds a fast TRBVH acceleration structure [1] then shoots rays against triangles and returns the results to you. That's it. - https://developer.nvidia.com/optix-prime-baking-sample

    Meanwhile, here's the most in-depth technical explanation I've been able to find (so far) for what an RT Core in the Turing architecture actually is and does:

    The RT core essentially adds a dedicated pipeline (ASIC) to the SM to calculate the ray and triangle intersection. It can access the BVH and configure some L0 buffers to reduce the delay of BVH and triangle data access. The request is made by SM. The instruction is issued, and the result is returned to the SM's local register. The interleaved instruction and other arithmetic or memory io instructions can be concurrent. Because it is an ASIC-specific circuit logic, performance/mm2 can be increased by an order of magnitude compared to the use of shader code for intersection calculation.  https://www.reddit.com/r/nvidia/comments/97qogl/former_nvidia_gpu_architect_what_is_rt_core_in/

     So in other words, OptiX Prime isn't "getting RTX support" because RT Cores are OptiX Prime - just in an exponentially higher performing dedicated hardware form.

     

    True too. But when will it happen though? Other big renderers are already following through. You can already combine two cards in Octane to get twice the memory (albeit with a bit of a performace hit). Not sure if the RT cores are speeding up their renders already, but they're definitely working on it. Nothing on Iray though, and I can't find any news about it. Their blog hasn't been updated since September 8th.

  • nicsttnicstt Posts: 11,714
    Aala said:
    RayDAnt said:
    Aala said:

    Any ideas?

    Most likely just the fact that it's beta software. Forgive me those with a better handle on software development lingo, but ideally the only key distinguishing factor between beta and final release software is efficiency. The reason for this is because a complex piece of software like Daz Studio relies on lots of general purpose programming libraries/APIs to do what it does. And since these sorts of libraries almost always include far more features/functionality than what any single piece of software could use (since they're "general purpose") their use always leads to a direct negative impact on runtime performance (since the OS has more code to search through each time the piece of software asks a library/API to do something.)

    Once a piece of software's code is finalized, a programmer can safely eliminate this type of performance hit by telling the software's compiler to arbitraily strip out all unused code (aka software runtime optimization).  However, since beta software's code is still actively being worked on, there are no guarantees as to which bits of code can safely be omitted. So no runtime optimization.

    Hence why the package size for the current official release of Daz Studio is around 303MB, whereas the current beta's is around 519MB - despite both versions sporting almost the same functionality. And also why they exhibit such different performance numbers when rendering the same scenes on identical hardware.

    The problem is that Iray isn't being developed by DAZ3D, but Nvidia (or whoever they contract to work on Iray). Iray is bsaically a plug in that we get out of the box and all DAZ3D does is integrate it with DAZ Studio. As soon as you click 'render', DAZ3D has no real control over how the scene is rendered. That's why you have two log changes on the other part of the forum, one for DAZ Studio itself, and one for Iray. But each version of Iray has some new feature, some bug fixes and stuff like that, and it has changed quite a bit since its first introduction. Remember the SSS bug? Iray's bad handling of that forced skin shaders to be more on the blue side until they fixed it. And now, as it happens, Iray has changed again between 4.10 and 4.11 Beta. I'm just not sure how.

    There has been a change relating to normal maps, which I believe is one reason 4.11 is slower.

  • nicsttnicstt Posts: 11,714
    artphobe said:

    Used GTX 1080 vs new RTX 2060?

    2060 has way fewer cuda cores but it has tensor stuff.

    Which is a better buy?

    1080 has more RAM; expensive paperweights don't render at all (when scene drops to CPU).

    It's down to if you feel you need the extra RAM; personally, 8 should be the minimum reccommended for Studio. Sure it can work, and well with less, but we're talking about a much better user experience imo

  • kameneko said:

    I've rendered the test scene from SY:

    CPU + GPU: 11m and 12s to finish (from Texture Shaded preview, Optix off, memory optimization)

    GPU Only: 32m 22s to finish (from Texture Shaded preview, Optix ON, memory optimization)

    From Iray preview with speed optimization the scene goes over my VRAM.

    My system specs:

    • Ryzen 5 1600
    • GTX 1060 3Gb
    • 4x4Gb 2667Mhz RAM
    • Samsung 970 Evo 250Gb

    I guess I need an upgrade! xD

    What seems strange to me are other benchmarks posted here with a 1060 6Gb, that take 6,5 minutes, but the CUDA difference should be of just 10%!

    Is there a simple list of average benchmarks? It would be really useful to see what GPU to buy, since this thread is too long and contains too many comments other than benchmarks...it would be nice something like "GPU only: 1050 in 15min, 1060 in 10 min, 1070 in 7min, 1080, 2060, 2070, 2080..." etc.

    6gb ram vs 3 gb ram in the 1060s is a significant diffrance.  DAZ's minimul spec for iray is 4gb.  1060 3gb is to small.

  • AalaAala Posts: 140
    nicstt said:
    Aala said:
    RayDAnt said:
    Aala said:

    Any ideas?

    Most likely just the fact that it's beta software. Forgive me those with a better handle on software development lingo, but ideally the only key distinguishing factor between beta and final release software is efficiency. The reason for this is because a complex piece of software like Daz Studio relies on lots of general purpose programming libraries/APIs to do what it does. And since these sorts of libraries almost always include far more features/functionality than what any single piece of software could use (since they're "general purpose") their use always leads to a direct negative impact on runtime performance (since the OS has more code to search through each time the piece of software asks a library/API to do something.)

    Once a piece of software's code is finalized, a programmer can safely eliminate this type of performance hit by telling the software's compiler to arbitraily strip out all unused code (aka software runtime optimization).  However, since beta software's code is still actively being worked on, there are no guarantees as to which bits of code can safely be omitted. So no runtime optimization.

    Hence why the package size for the current official release of Daz Studio is around 303MB, whereas the current beta's is around 519MB - despite both versions sporting almost the same functionality. And also why they exhibit such different performance numbers when rendering the same scenes on identical hardware.

    The problem is that Iray isn't being developed by DAZ3D, but Nvidia (or whoever they contract to work on Iray). Iray is bsaically a plug in that we get out of the box and all DAZ3D does is integrate it with DAZ Studio. As soon as you click 'render', DAZ3D has no real control over how the scene is rendered. That's why you have two log changes on the other part of the forum, one for DAZ Studio itself, and one for Iray. But each version of Iray has some new feature, some bug fixes and stuff like that, and it has changed quite a bit since its first introduction. Remember the SSS bug? Iray's bad handling of that forced skin shaders to be more on the blue side until they fixed it. And now, as it happens, Iray has changed again between 4.10 and 4.11 Beta. I'm just not sure how.

    There has been a change relating to normal maps, which I believe is one reason 4.11 is slower.

    I think it might be something else, a bug I might have stumbled upon. I'll post in much more detail in the next post.

  • AalaAala Posts: 140
    edited January 2019

    I've just created a new benchmark scene with two variations for testing. It's a simple Cornell Box, used for typical Raytracing tests to match in-render lighting with real word lighting. One benchmark is set to 1000 iterations maximum, the other is set to two minutes. The point is to have a scene without any textures in it so that it loads and starts rendering as fast as possible and is completed fast enough so we don't waste too much time testing. You can find the two scenes attached down below.

    I've rendered the scenes solely on my Aorus GTX 1080 Ti G11, here are the results:

    • 01000 iterations after 150.241s. - 1k Iterations Test - DAZ Studio 4.10
    • 01000 iterations after 144.972s. - 1k Iterations Test - DAZ Studio 4.11 BETA
    • 00791 iterations after 120.656s. - 2 Minutes Test - DAZ Studio 4.10
    • 00814 iterations after 120.336s. - 2 Minutes Test - DAZ Studio 4.11 BETA

    And below you can see the different test result images (right-click open to new tab for greater detail, and swap between tabs to see the differences).

    The first two images are the differences between the 1000 iterations tests between Daz 4.10 (first image) and Daz 4.11 (second image)

    1000 Iterations Daz 4.10 1000 Iterations Daz 4.11

    And the images below are the differences between the 2 minutes tests between Daz 4.10 (first image) and Daz 4.11 (second image)

    2 Min Test Daz 4.10 2 Min Test Daz 4.11

    There are some slight differences in the images itself, especially in when the lights are reflected directly on the surfaces of the objects, and the SSS-enabled objects have some slight variations in the way they scatter light too. Surprisingly though, 4.11 Beta is actually rendering faster in both cases on my 1080 Ti, as you can see, unlike the other previous scenes that we've tested before. I was wondering what's up and spent the afternoon investigating.

    What I've found is this: There's some kind of a bug or intended feature that I'm not understanding when it comes to bump and normal maps. On the scene tab of both scenes, there's a hidden sphere shaded with the Iray Leather Surface that comes with the default Daz resources. I've made a slight modification where I put the normal map on the bump map too for testing purposes so that it loads correctly for everyone. And I've had some interesting results if I render the scene with the Leather Sphere set to visible on DAZ Studio 4.11 Beta:

    • 01000 iterations after 196.306s. - 1k Iterations Test LEATHER SPHERE VISIBLE With Bump and Normal - DAZ Studio 4.11 BETA
    • 01000 iterations after 147.766s. - 1k Iterations Test LEATHER SPHERE VISIBLE Without Bump Map - DAZ Studio 4.11 BETA
    • 01000 iterations after 145.723s. - 1k Iterations Test LEATHER SPHERE VISIBLE Without Normal Map - DAZ Studio 4.11 BETA
    • 01000 iterations after 145.869s. - 1k Iterations Test LEATHER SPHERE VISIBLE Without Bump or Normal Map - DAZ Studio 4.11 BETA

    Those are some weird results as you can see. The render is slowed down significantly only when both maps are set on the shader. At first, I thought it's maybe because I'm using the same map for both, so I went online and searched google for a leather bump map, set it instead of the normal one. I still got the same results. This is incredibly weird for me. And I do not experience the same kind of slowdowns in 4.10. Unfortunately, right now it's really late and I can't start testing the scene with characters instead. But I would greatly appreciate it if some of you guys performed the same tests to see if you get the same results. 

    duf
    duf
    Iray Cornell Box 1k Iteration Limit.duf
    138K
    duf
    duf
    Iray Cornell Box 2 min Time Limit.duf
    138K
    Post edited by Aala on
  • LenioTGLenioTG Posts: 2,116
    kameneko said:

    I've rendered the test scene from SY:

    CPU + GPU: 11m and 12s to finish (from Texture Shaded preview, Optix off, memory optimization)

    GPU Only: 32m 22s to finish (from Texture Shaded preview, Optix ON, memory optimization)

    From Iray preview with speed optimization the scene goes over my VRAM.

    My system specs:

    • Ryzen 5 1600
    • GTX 1060 3Gb
    • 4x4Gb 2667Mhz RAM
    • Samsung 970 Evo 250Gb

    I guess I need an upgrade! xD

    What seems strange to me are other benchmarks posted here with a 1060 6Gb, that take 6,5 minutes, but the CUDA difference should be of just 10%!

    Is there a simple list of average benchmarks? It would be really useful to see what GPU to buy, since this thread is too long and contains too many comments other than benchmarks...it would be nice something like "GPU only: 1050 in 15min, 1060 in 10 min, 1070 in 7min, 1080, 2060, 2070, 2080..." etc.

    6gb ram vs 3 gb ram in the 1060s is a significant diffrance.  DAZ's minimul spec for iray is 4gb.  1060 3gb is to small.

    Well...I did not know I would have discovered Daz when I first built my PC, and now I'm saving up but a new GPU is not cheap...especially if these Daz Sales keep eating my wallet xD

    Anyway, I assure you that, even if it's very uncomfortable, you can achieve something with just 3Gb! ^^

  • RayDAntRayDAnt Posts: 1,120
    edited January 2019

    Aala, I decided to do some digging of my own through the Iray changelogs from the DS 4.11 beta thread, and although I’m no computer graphics expert (my cs degree was in hci - not cgi unfortunately) I’m fairly certain pretty much every graphical anomaly/difference in renderer performance observed here between the Iray renderer version found in DS 4.10 and that found in the current beta is just the result of documented bug fixes/feature upgrades. It’s just a question of knowing what to look for. Eg:

    The second image seems to have correct reflections of light in the glass ball. The first one is simply broken.

    Is the caustics enabled in the scene?

    Nope, I checked. Seems to me too that they've fixed some kind of a reflection/refraction bug but I don't see it in the logs, or at least I don't know what I'm looking for.

     

    ​The changelog for Iray 2017.1 beta, build 296300.616 mentions the following:

    • Fixed Bugs

      • Iray Photoreal
        • When using a solid color as the backplate, along with inverse-tonemapping of the backplate enabled, and enabled backplate contributions for reflections and/or refractions, the contribution of the backplate now has correct intensity (used to be too dark, depending on tonemapper settings).

    Most of the benchmarking scenes discussed in this thread feature reflections and/or refractions resulting from interactions between formal light sources and backplates (light emissive textures like HDRI skydomes.) And although the changelog only mentions it as an issue for solid color backplates, it stands to reason that this would also be a noticeable issue with high intensity light sources originating as part of a backplate (as is the case with the very noticeably incorrectly reflected/refracted light source found in Outrider42’s benchmarking scene under DS 4.10) since such spots are technically just a solid color grouping of pixels.

    Similarly, regarding what you’ve observed with DS 4.11 beta taking longer to render with that bump/normal map combination present, the changelog for Iray 2017.1.4, build 296300.6298 contains the following:

    Fixed Bugs

    • ray Photoreal
      • The normal buffer now outputs a weighted average of all BSDF bump maps, not only the main material bump.

    The implication being that previous Iray versions (including the one found in DS 4.10) were just ignoring the existence of traditional bump maps any time a normal map (which is just a 3d upgrade of a bump map) was also given for a particular object. The version of Iray found in the current DS beta isn’t slower at this than the version in DS 4.10. The Iray version in DS 4.10 is just finishing it faster because it isn’t actually doing the computational work.

    Post edited by RayDAnt on
  • tj_1ca9500btj_1ca9500b Posts: 2,047
    edited January 2019

    Just benched my new rig.. finally..

    Threadripper 2990WX and 3x2080ti's.  Didn't bench with the CPU since it didn't make much of a difference (about 10secs off the first run of Outriders scene)

    DS 4.11 beta

    Outriders scene:

    1m 47 (Optix off)
    1m 49 (on)

    SY's scene:

    30s (OptiX off)

    23s (on)

    So there you go.. fingers crossed some RTX stuff comes down the pipeline to speed it up some more.

    Any chance that we can talk you into benching the 2990WX on it's own?  For comparison purposes of course!

    Yeah, it'll be slower, but this way we can compare the results to say a 16 core 1950X/2950X...

    The older/shorter benchmark should be fine if you are game.

    Post edited by tj_1ca9500b on
  • outrider42outrider42 Posts: 3,679
    edited January 2019

    > I have a funny feeling that it takes just a wee bit more than swapping out the DLL file to switch Prime to full Optix. 

    Swapping out the DLL file was not meant to change OptiX Prime to OptiX (for that you would need to swap other DLLs, not cuDNN.dll).

    It was meant to allow AI denoiser code path to use CUDA 10.0 runtime which should in theory support Turing hardware, and to test whether newer DLL uses Tensor cores for denoising or not.

    There is a 12 page paper investigating this topic and they determined this to be the case. 

    I read the paper, they determined that you can either have performance (btw, they achieved only 74% of theoretical peak), or precision, but not both.

    Many HPC computational algorithms require double precision for proper convergence of the results, you can simply forget half-precision Tensor cores for that purpose.

    Read this and you will understand why half-precision is not well suited for HPC or pretty much anything other than Tensor and image processing:
    https://en.wikipedia.org/wiki/Half-precision_floating-point_format

     

    You carefully omitted part of the quote you referred to. Here it is in full.

    "In conclusion, despite the Volta microarchitecture with Tensor Cores has only been recently released, it is possible to program Tensor Cores for HPC applications using three approaches and achieve considerable performance boost at the cost of decreased precision. We expect the programming interfaces for NVIDIA Tensor Cores to evolve and allow increased expressiveness and performance. In particular, we noted that the measured Tensor Core maximum performance is still 74% the theoretical peak, leaving room for improvement. While the precision loss due to mixed precision might be an obstacle for the uptake of NVIDIA Tensor Cores in HPC, we showed that it is possible to decrease it at the cost of increased computations. For all these reasons, it is very likely that HPC applications will strongly benefit from using of NVIDIA Tensor Cores. In the future we will focus on testing Tensor Cores in real-world HPC applications, such as Nek5000 [23], [24] or Fast Multipole Method-accelerated FFT [25]. "

    Note those key words that you gloss over. In spite of the drawbacks, they STILL CONCLUDE HPC will benefit from Tensor. Not just a little, but they specifically use the term "strongly". And that is the bottom line. You can pick through this with a fine tooth comb as much as you want to, that does not change the final conclusion they made.

    Besides, the whole point I was making was not just HPC. My point is that Tensor can be used for ANYTHING. Daz Studio and Iray are not HPC applications. You even state yourself that Tensor can be used for image processing...is a render not an image process?

    ---------------------------------------------------------------

    Daz 4.11 has no drivers for Turing. None. Daz 4.11 released in July. The actual Iray plugin in 4.11, Iray 2018.0.1, build 302800.3495, further predates that. This update contains drivers for Volta, and mentions Volta by name, but not Turing. This strongly suggests that the Iray plugin we see in 4.11 is not yet optimized for Turing, and that includes the OptiX Prime acceleration. That is why you see weird times with Optix enabled on Turing GPUs. Optix Prime indeed may not add RT core support, but it could be optimized better, further increasing the performance over Pascal. But we do not know for certain. I assume it will, and that you will see further speed enhancements. Support for Tensor could change how Iray behaves. And if Iray gets the full Optx plugin, things could get very interesting indeed. The best case would be for Iray to offer both options to its users. The full Optix will be slower for anything before Turing, but with Turing, it should be quite fast.

    I have said it before, but it is a very bad idea to compare render times based on convergence percentage. Regardless of what you set the convergence to, convergence can differ from run to run, giving different iteration counts. If you have different iteration counts, then almost certainly your render times will differ as well. But more over, the way Iray calculates convergence can change in different SDK plugin updates! So what Daz 4.10 with Iray 2017 deems 100% converged may in fact be different from what Daz 4.11 Iray 2018 deems 100% converged. This is why my bench caps at 5000 iterations and runs all the way through to that 5000 number. Any other benchmark you make NEEDS TO HAVE AN ITERATION CAP in order to properly compare times. This is a limitation of the SY bench, it does not always run to the 5000 cap, it can end much sooner. This can skew results. Daz_RAWB's bench does not take this into consideration, either. In the last post, Daz 4.11 ran over 1,000 fewer iterations than 4.10. That basically invalidates that benchmark. A better solution would be to cap the iteration count at perhaps 1500 or less and then compare the render times.

    Post edited by outrider42 on
  • bk007dragonbk007dragon Posts: 113
    edited January 2019
    kameneko said:
    kameneko said:

    I've rendered the test scene from SY:

    CPU + GPU: 11m and 12s to finish (from Texture Shaded preview, Optix off, memory optimization)

    GPU Only: 32m 22s to finish (from Texture Shaded preview, Optix ON, memory optimization)

    From Iray preview with speed optimization the scene goes over my VRAM.

    My system specs:

    • Ryzen 5 1600
    • GTX 1060 3Gb
    • 4x4Gb 2667Mhz RAM
    • Samsung 970 Evo 250Gb

    I guess I need an upgrade! xD

    What seems strange to me are other benchmarks posted here with a 1060 6Gb, that take 6,5 minutes, but the CUDA difference should be of just 10%!

    Is there a simple list of average benchmarks? It would be really useful to see what GPU to buy, since this thread is too long and contains too many comments other than benchmarks...it would be nice something like "GPU only: 1050 in 15min, 1060 in 10 min, 1070 in 7min, 1080, 2060, 2070, 2080..." etc.

    6gb ram vs 3 gb ram in the 1060s is a significant diffrance.  DAZ's minimul spec for iray is 4gb.  1060 3gb is to small.

    Well...I did not know I would have discovered Daz when I first built my PC, and now I'm saving up but a new GPU is not cheap...especially if these Daz Sales keep eating my wallet xD

    Anyway, I assure you that, even if it's very uncomfortable, you can achieve something with just 3Gb! ^^

    Very true, I started with less.  My first iray card was an NVIDIA 640 2gb Ram 384 Cuda Cores on a 2010 ASUS cm5571 with a Core 2 Due E5584 and 6GB @ 1666 Ram.   You are starting off better than I was.  

    When I upgraded to a 1070 Ti it made a world of diffrance.   Once you get a better card, your render tims will drop significantly.

    Post edited by bk007dragon on
  • LenioTGLenioTG Posts: 2,116
    kameneko said:
    kameneko said:

    I've rendered the test scene from SY:

    CPU + GPU: 11m and 12s to finish (from Texture Shaded preview, Optix off, memory optimization)

    GPU Only: 32m 22s to finish (from Texture Shaded preview, Optix ON, memory optimization)

    From Iray preview with speed optimization the scene goes over my VRAM.

    My system specs:

    • Ryzen 5 1600
    • GTX 1060 3Gb
    • 4x4Gb 2667Mhz RAM
    • Samsung 970 Evo 250Gb

    I guess I need an upgrade! xD

    What seems strange to me are other benchmarks posted here with a 1060 6Gb, that take 6,5 minutes, but the CUDA difference should be of just 10%!

    Is there a simple list of average benchmarks? It would be really useful to see what GPU to buy, since this thread is too long and contains too many comments other than benchmarks...it would be nice something like "GPU only: 1050 in 15min, 1060 in 10 min, 1070 in 7min, 1080, 2060, 2070, 2080..." etc.

    6gb ram vs 3 gb ram in the 1060s is a significant diffrance.  DAZ's minimul spec for iray is 4gb.  1060 3gb is to small.

    Well...I did not know I would have discovered Daz when I first built my PC, and now I'm saving up but a new GPU is not cheap...especially if these Daz Sales keep eating my wallet xD

    Anyway, I assure you that, even if it's very uncomfortable, you can achieve something with just 3Gb! ^^

    Very true, I started with less.  My first iray card was an NVIDIA 640 2gb Ram 384 Cuda Cores on a 2010 ASUS cm5571 with a Core 2 Due E5584 and 6GB @ 1666 Ram.   You are starting off better than I was.  

    When I upgraded to a 1070 Ti it made a world of diffrance.   Once you get a better card, your render tims will drop significantly.

    Eheh, the time will come that we'll render in real time at a much higher quality! :D
    For now, I'd be happy to see the Batch Renderer on sale xD

  • AalaAala Posts: 140
    RayDAnt said:

    Aala, I decided to do some digging of my own through the Iray changelogs from the DS 4.11 beta thread, and although I’m no computer graphics expert (my cs degree was in hci - not cgi unfortunately) I’m fairly certain pretty much every graphical anomaly/difference in renderer performance observed here between the Iray renderer version found in DS 4.10 and that found in the current beta is just the result of documented bug fixes/feature upgrades. It’s just a question of knowing what to look for. Eg:

    The second image seems to have correct reflections of light in the glass ball. The first one is simply broken.

    Is the caustics enabled in the scene?

    Nope, I checked. Seems to me too that they've fixed some kind of a reflection/refraction bug but I don't see it in the logs, or at least I don't know what I'm looking for.

     

    ​The changelog for Iray 2017.1 beta, build 296300.616 mentions the following:

    • Fixed Bugs

      • Iray Photoreal
        • When using a solid color as the backplate, along with inverse-tonemapping of the backplate enabled, and enabled backplate contributions for reflections and/or refractions, the contribution of the backplate now has correct intensity (used to be too dark, depending on tonemapper settings).

    Most of the benchmarking scenes discussed in this thread feature reflections and/or refractions resulting from interactions between formal light sources and backplates (light emissive textures like HDRI skydomes.) And although the changelog only mentions it as an issue for solid color backplates, it stands to reason that this would also be a noticeable issue with high intensity light sources originating as part of a backplate (as is the case with the very noticeably incorrectly reflected/refracted light source found in Outrider42’s benchmarking scene under DS 4.10) since such spots are technically just a solid color grouping of pixels.

    Seems like it, but this seems to be a simple bug fix that doesn't affect performance (or might be improving it).

    RayDAnt said:

    Similarly, regarding what you’ve observed with DS 4.11 beta taking longer to render with that bump/normal map combination present, the changelog for Iray 2017.1.4, build 296300.6298 contains the following:

    Fixed Bugs

    • ray Photoreal
      • The normal buffer now outputs a weighted average of all BSDF bump maps, not only the main material bump.

    The implication being that previous Iray versions (including the one found in DS 4.10) were just ignoring the existence of traditional bump maps any time a normal map (which is just a 3d upgrade of a bump map) was also given for a particular object. The version of Iray found in the current DS beta isn’t slower at this than the version in DS 4.10. The Iray version in DS 4.10 is just finishing it faster because it isn’t actually doing the computational work.

    Okay this is what I don't understand. Why should having both the bump and normal map active produce such a big slowdown, but having one of each be much faster? It has got to be a bug. Have you tested out the scene with your Titan RTX? It would be interesting to see the results.

  • Robert FreiseRobert Freise Posts: 4,247
    edited January 2019

    Why are you using both

    A bump is just the old basic version and normal maps are the improved newer version

    Bump Map / Normal Maps

    • Bump Maps are the most basic form of this, as they are only one channel of information (greyscale). This is sort of like a height map (darker being deeper, brighter being higher). It heavily relies on the existing normal information, and combines with it to make the result look bumpier than it really is. It's an older concept, limited in what it can do, and as a result is mostly just good for very basic and minor types of surface bumps.

    • Normal maps are a fancier form of bump mapping. It uses the red, green, and blue channels of the image to control the direction of each pixel's normal. It still relies on the original vertex normal information, but lets you define/fake a surface more accurately than a simpler bumpmap can

    Post edited by Robert Freise on
  • bluejauntebluejaunte Posts: 1,859
    RayDAnt said:

    The implication being that previous Iray versions (including the one found in DS 4.10) were just ignoring the existence of traditional bump maps any time a normal map (which is just a 3d upgrade of a bump map) was also given for a particular object. The version of Iray found in the current DS beta isn’t slower at this than the version in DS 4.10. The Iray version in DS 4.10 is just finishing it faster because it isn’t actually doing the computational work.

    I would have noticed in 4.10 and before if bump/normal didn't stack, so I'd rule out that.

  • RayDAntRayDAnt Posts: 1,120
    edited January 2019
    Aala said:

    Seems like it, but this seems to be a simple bug fix that doesn't affect performance (or might be improving it).

    Yeah, I don't see this leading to a big performance difference either. However it does lead to a visual difference in the final render. Which is an equally valid part imo of what you brought up concerning rendering variances between DS 4.10 and 4.11 beta.

    Okay this is what I don't understand. Why should having both the bump and normal map active produce such a big slowdown, but having one of each be much faster? It has got to be a bug.

    A bump map is a collection of one-dimensional offsets applied to the positional coordinates of triangles on the surfaces of an object. A normal map is a collection of three-dimensional offsets applied to the positional coordinates of triangles on the surfaces of an object. Having both active at once on an object in a scene (especially when that object happens to be a sphere) would mean introducing the need for at least two extra calculations to the process of positioning each and every point on that objects' surface. And those sorts of micro calculations add up.

    Have you tested out the scene with your Titan RTX? It would be interesting to see the results.

    I would if I could, but it's impossible to render ANYTHING in DS 4.10 with a Turing card due to the lack of Volta support. :(

    I am planning on doing a full gauntlet of the 1000 iterations version and adding that to my earlier post of collected benchmark stats in case people find it useful. You can never really have too many benchmarks imo.

    Post edited by RayDAnt on
  • RayDAntRayDAnt Posts: 1,120
    edited January 2019

    I would have noticed in 4.10 and before if bump/normal didn't stack

    Who said anything about them not stacking? The Iray change log in question (repeated below for sake of convenience) states:

    2017.1.4, build 296300.6298

    Fixed Bugs

    • ray Photoreal
      • The normal buffer now outputs a weighted average of all BSDF bump maps, not only the main material bump.

    Weighted averaging is obviously a much more mathematically complex process than simply stacking (summing) things together. And we aren't even talking about bump/normal map interactions in general - just in cases where both are used on a sphere (since that was the specific use case in Aala's benchmarking scene where a seemingly mysterious performance hit was observed.)

    Post edited by RayDAnt on
  • fred9803fred9803 Posts: 1,558

    I'm hugely confused Ted. Half the test results on the same cards are reporting vastly differerent render times, and the other half are reporting times when they don't let the render go to 100% convergence at 05000 iterations.

    It's very hard to compare apples with apples in these cases. Everyone know the last 5% of a render is the slowest so unless you let it finish the times are meaningless for the purpose of comparison.

    For what it's worth here are mine on a GTX 2080 non-OC on an older system..... and I did conduct the test as it was meant to be conducted.

  • bluejauntebluejaunte Posts: 1,859
    RayDAnt said:

    I would have noticed in 4.10 and before if bump/normal didn't stack

    Who said anything about them not stacking? The Iray change log in question (repeated below for sake of convenience) states:

    2017.1.4, build 296300.6298

    Fixed Bugs

    • ray Photoreal
      • The normal buffer now outputs a weighted average of all BSDF bump maps, not only the main material bump.

    Weighted averaging is obviously a much more mathematically complex process than simply stacking (summing) things together. And we aren't even talking about bump/normal map interactions in general - just in cases where both are used on a sphere (since that was the specific use case in Aala's benchmarking scene where a seemingly mysterious performance hit was observed.)

    Oh I see. Apologies, I thought you meant a bump map might be completely ignored when a normal map is used.

  • This is not the thread for another acrimonious argument over hardware - please drop the subject if the posts cannot be kept civil.

  • bluejauntebluejaunte Posts: 1,859

     

    Iteration count is just another way of limiting rendering time (other ways being max time itself, max number of samples, and pixel convergence %), it does not mean you cannot end with less iterations when the scene pixels converge faster to their final value.

    What does convergence actually mean? When does a pixel count as converged?

  • RayDAntRayDAnt Posts: 1,120
    edited February 2019

     

    Iteration count is just another way of limiting rendering time (other ways being max time itself, max number of samples, and pixel convergence %), it does not mean you cannot end with less iterations when the scene pixels converge faster to their final value.

    What does convergence actually mean? When does a pixel count as converged?

    Each time Periodically during the rendering process, as Iray completes a new iteration of a scene it goes through and compares the newly computed value of each and every pixel to what it was the last time it checked, and if the two values are within a certain threshold of difference from each other (as defined by the "Rendering Quality" parameter found under Render Settings in Daz Studio) it flags that pixel as "converged". Iray then keeps a running tally of how many pixels in the current intermediately rendered image are flagged as "converged" versus the pixel count as a whole, and uses this ratio ("Rendering Converged Ratio" in Render Settings) as one of the key parameters for determining when a render is completed.  It's actually a very elegant way of solving what is technically an unsolvable problem (determining a point at which a theoretically endless process of iterative computation like raytracing can fairly said to be "complete".)

    So in other words,

    Q: When does a pixel count as converged?

    A: When the value of "Rendering Quality" says so.

    What does this all actually mean? The default value of "Rendering Quality" in all versions of DS (afaik) is 10. And I've never come across anyone changing it. Increasing it (it has a max value of 10000...) leads to an increase in per-pixel rendering quality at the cost of a linear increase in rendering time (ie. a render at RQ=10 taking ten minutes to "converge" will take twenty minutes to "converge" at RQ=20.)

    Otherwise there really isn't much more (in terms of concrete things) to say on the matter - other than point out that convergance % can be used as a valid performance benchmark (as long as people stick to the same value for Iray's "Rendering Quality" parameter.)

    What can I say - 3d rendering is a cryptic business...

     

    ETA: clarity. Plus better info.

    Post edited by RayDAnt on
Sign In or Register to comment.