Hi, updated results with OptiX 6.0 and Fermat 2.0. OTOY’s latest scores also included. The perf is just amazing!
[url]http://boostclock.com/show/000250/gpu-rendering-nv-rtxon-gtx1080ti-rtx2080ti-titanv.html[/url]
Thanks for sharing.
I guess OptiX mesh viewer doesn’t enable RTX execution strategy while it uses Triangle APIs because RTX is disabled unless we set global attribute to enable RTX mode.
Did you modify that sample to enable RTX-mode?
If you are using optix 6, then optixMeshViewer should be using RTX mode (which is now the default).
1 Like
Yep, in OptiX SDK 6.0 the sample defaults to use_tri_api = true - GeometryTriangles interface.
This is how the results were generated:
REM RTX OFF - dragon_vrip
optixMeshViewer.exe --mesh ./mesh/dragon_vrip.ply --file out_dragon_vrip_rtxoff.ppm --ignore-materials --nopbo --no-triangle-api --width 7680 --height 4320 --iter 128
REM RTX ON - dragon_vrip
optixMeshViewer.exe --mesh ./mesh/dragon_vrip.ply --file out_dragon_vrip_rtxon.ppm --ignore-materials --nopbo --width 7680 --height 4320 --iter 128
Note that you are not testing exactly what I think you think you are testing :)
You are testing triangle API on vs triangle API off – both in RTX mode on Turing. That means that in both cases you are:
a) using RTX mode
b) using RTCores for BVH traversal
What you are doing is essentially disabling RTCore base triangle intersection. This has a fairly high cost because execution is forced to return to the SM mid-traversal, then return to the RTCore to resume Acceleration traversal.
If you were to also disable RTCore-based traversal, you should get an even bigger perf diff between your two test modes. Unfortunately, there isnt a clean (no side-effect) way of doing this. You can either run the exact same code (including triangle API) on Turning and non-turing hardware (which introduces the additional variable of differing arch/hardware) or run in RTX execution mode ON and OFF (which introduces a bunch of side effects since the internal JIT compiler is different).
TLDR; you are actually testing built-in primitive intersection vs custom primitive intersection.
Oh, really?
The programming guide says RTX is disabled by default (3.1.4 even on Web version).
Well, it says “As of OptiX 5.2”, but I have supposed OptiX 5.2 to be essentially the same version to 6.0.
Whoops, looks like I need to file a bug on the documentation. It should be on by default. You can also check this by calling rtGlobalGetAttribute( RT_GLOBAL_ATTRIBUTE_ENABLE_RTX, … ) in your app.
Thanks for bringing this to our attention.
As you say, RTX mode seems to be “enabled” by default because the program reports an exception that “GeometryTriangles works only on RTX mode enabled” if I explicitly set RT_GLOBAL_ATTRIBUTE_ENABLE_RTX to 0.
However rtGetGlobalAttribute(RT_GLOBAL_ATTRIBUTE_ENABLE_RTX, …) returns 0 even before explicitly setting the attribute to 0 in my environment.
int32_t RTXEnabled = -1;
rtGlobalGetAttribute(RT_GLOBAL_ATTRIBUTE_ENABLE_RTX, sizeof(int32_t), &RTXEnabled); // The value is zero in my env (RTX 2070)
RTXEnabled = 0;
rtGlobalSetAttribute(RT_GLOBAL_ATTRIBUTE_ENABLE_RTX, sizeof(int32_t), &RTXEnabled); // explicitly disable RTX mode.
// Set up context
context = Context::create();
... Now this program reports the exception and will shut down.
At least the initial call to rtGetGlobalAttribute(RT_GLOBAL_ATTRIBUTE_ENABLE_RTX, …) seems to return incorrect result…
Could you verify the behavior of this function?
Sorry for disturbing this topic a bit m_nyers ;)
Make that whoops x2 :)
Looking at the code, yes rtx is the default. However, I see how GetAttribute is incorrectly reporting the value unless you explicitly set it. We will get this fixed.
Thanks again
shocker.0x15: No worries, this is really useful information and a bug caught! :)
Keith: Thanks for the details. Just some examples to make sure I understand things correctly. :)
If I have an old OptiX program recompiled for OptiX 6.0 I have RTX mode on: this means I got RTCore acceleration for BVH traversal, but no HW based ray-tri acceleration. Is this correct?
If I have an old OptiX program recompiled for OptiX 6.0 and I disable RTX mode: I got the same behaviour as with the old OptiX execution model. Is this correct?
Thanks for your help!
Oh, one more thing: What goes on in the background running on pre-Turing hardware using the triangle API? Thanks!
If I have an old OptiX program recompiled for OptiX 6.0 I have RTX mode on: this means I got RTCore acceleration for BVH traversal, but no HW based ray-tri acceleration. Is this correct?
Correct. RTCore BVH traversal occurs IFF:
- Turing RTX hardware is used
- Global attribute RTX_ENBABLED is ON (which is the default)
If either of these conditions are not met, optix’s software implementation of BVH traversal is run on the SM
RTCore fixed-function triangle intersection occurs IFF:
- Turing RTX hardware is used
- Global attribute RTX_ENBABLED is ON (which is the default)
- Triangle API is used to specify your triangle geometry
If any of these requirements is not met, then one of two things is done:
- If RTgeometrytriangles are used, then optix will use its software implementation of watertight tri intersection on the SM
- If RTgeometry is used, optix uses your custom intersector/bbox program on the SM, completely unaware of the underlying geometric representation
If I have an old OptiX program recompiled for OptiX 6.0 and I disable RTX mode: I got the same behaviour as with the old OptiX execution model. Is this correct?
If you disable RTX mode, you are not only disabling RTCore usage, you are using a different (legacy) JIT compilation pipeline. Compilation will be slower, caching less effective, etc. You should really not be using non-RTX mode unless you have a specific reason to do so (like the need for non-RTX supported features like Selectors).
Thanks
k
Thank you for the detailed answer!
Indeed, if I disable RTX mode in the meshViewer sample the delta is even bigger regarding RTX On/Off modes.