At NVIDIA, everything is RTX, but not everything is AI. In our article, we clarify what this means exactly.
RTX as an umbrella term
Back in the fall of 2018, NVIDIA presented the first GeForce RTX series, which used the Turing architecture and introduced a number of interesting innovations. Since then, of course, two new generations have been born, but this was the point when the RTX indicator clearly entered the public consciousness. Originally, it seemed that this would be NVIDIA’s own name for ray tracing, but it has since turned out that the company labels everything with RTX, which is somehow related to a certain technology that can be used in games or beyond. Because of this, RTX has become a collective term, which can certainly cause serious confusion in the minds, since many people still only think of ray tracing when they hear these three letters.
Because of the above, it is worth breaking down what NVIDIA actually means by this. On the one hand, there is obviously ray tracing, but it is important to emphasize that it is a completely standard procedure, the game should work with an appropriately modern version of DirectX 12 or Vulkan. The two mentioned APIs offer roughly the same thing in terms of ray tracing, which is why we primarily present DirectX Raytracing, but Vulkan is also very, very similar.
During the presentation of the first DirectX Raytracing, which is usually called DXR 1.0, Microsoft offered a so-called dynamic shader based raytracing. It mostly worked, but it wasn’t optimized for performance at all. The system basically fired the rays, the hardware used the acceleration structure to find where it would hit a triangle, if at all, and a hit or miss shader could come accordingly. Whichever was called by the program, it was linked to the corresponding connection table, and based on this, the system was able to share the necessary data with the hit or miss shader, that is, the path of a ray was followed in this form for as long as it lasted.
Control Raytracing off and on (source: NVIDIA) (+)
There was no problem with this in itself and there is no problem today, in fact, it is a well-functioning technique if the given game runs complex shaders in addition to the use of several virtual materials on the surfaces, since with DXR 1.0 the system manages the scheduling of work related to shading. The problem could have come from various limitations, among other things, the accelerator structure cannot be connected at every shader step, it requires a state object managed at the API level and a connection table for shaders, and the system does not allow the management of relatively low-level ray traversal.
Control Raytracing off and on (source: NVIDIA) (+)
In response to these factors, Microsoft later introduced DXR 1.1, which offers so-called inline raytracing. This is actually not a replacement of 1.0, but an addition, since version 1.1 eliminates the connection table compared to the previous method, and there will be no more separated dynamic shaders. Instead, the original shader already contains the context structure and tells the hardware to start the traversal step. If a ray has a hit, the function returns, but the context structure is already there in the shader, with which the work can start immediately, there is no need to start any data movement or a separate dynamic shader for this. In return, the scheduling of work related to shading is also removed from the system, but this is favorable in most cases, as it allows for more effective optimization. It is only in rare cases that the original 1.0 specification works faster.
The good news is that users don’t really have to worry about this, because any GPU capable of hardware-accelerated ray tracing supports both DXR 1.0 and 1.1, so developers can freely choose which option to include in their games; nowadays, the latter is more common, but there are exceptions.
With the RTX flag, NVIDIA doesn’t really differentiate between the two ray tracing methods with different specifications, and it’s also considered irrelevant which API they’re used in. The company probably sees that it would be too complicated to communicate this to customers, so they prefer simpler messages, but from a technical point of view it is important to emphasize that there are several completely standard methods involved.
The article is not over yet, please turn the page!
Source: prohardver.hu
