O Rayly? Ya Rayly. No Ray!
Yup. That raytracing… but it’s to supplement rasterization for now.
Microsoft has just announced a raytracing extension to DirectX 12, called DirectX Raytracing (DXR), at the 2018 Game Developer's Conference in San Francisco.
The goal is not to completely replace rasterization… at least not yet. This effect will be mostly implemented for effects that require supplementary datasets, such as reflections, ambient occlusion, and refraction. Rasterization, the typical way that 3D geometry gets drawn on a 2D display, converts triangle coordinates into screen coordinates, and then a point-in-triangle test runs across every sample. This will likely occur once per AA sample (minus pixels that the triangle can’t possibly cover — such as a pixel outside of the triangle's bounding box — but that's just optimization).
For rasterization, each triangle is laid on a 2D grid corresponding to the draw surface.
If any sample is in the triangle, the pixel shader is run.
This example shows the rotated grid MSAA case.
A program, called a pixel shader, is then run with some set of data that the GPU could gather on every valid pixel in the triangle. This set of data typically includes things like world coordinate, screen coordinate, texture coordinates, nearby vertices, and so forth. This lacks a lot of information, especially things that are not visible to the camera. The application is free to provide other sources of data for the shader to crawl… but what?
- Cubemaps are useful for reflections, but they don’t necessarily match the scene.
- Voxels are useful for lighting, as seen with NVIDIA’s VXGI and VXAO.
This is where DirectX Raytracing comes in. There’s quite a few components to it, but it’s basically a new pipeline that handles how rays are cast into the environment. After being queued, it starts out with a ray-generation stage, and then, depending on what happens to the ray in the scene, there are close-hit, any-hit, and miss shaders. Ray generation allows the developer to set up how the rays are cast, where they call an HLSL instrinsic instruction, TraceRay (which is a clever way of invoking them, by the way). This function takes an origin and a direction, so you can choose to, for example, cast rays only in the direction of lights if your algorithm was to, for instance, approximate partially occluded soft shadows from a non-point light. (There are better algorithms to do that, but it's just the first example that came off the top of my head.) The close-hit, any-hit, and miss shaders occur at the point where the traced ray ends.
To connect this with current technology, imagine that ray-generation is like a vertex shader in rasterization, where it sets up the triangle to be rasterized, leading to pixel shaders being called.
Even more interesting – the close-hit, any-hit, and miss shaders can call TraceRay themselves, which is used for multi-bounce and other recursive algorithms (see: figure above). The obvious use case might be reflections, which is the headline of the GDC talk, but they want it to be as general as possible, aligning with the evolution of GPUs. Looking at NVIDIA’s VXAO implementation, it also seems like a natural fit for a raytracing algorithm.
Speaking of data structures, Microsoft also detailed what they call the acceleration structure. Each object is composed of two levels. The top level contains per-object metadata, like its transformation and whatever else data that the developer wants to add to it. The bottom level contains the geometry. The briefing states, “essentially vertex and index buffers” so we asked for clarification. DXR requires that triangle geometry be specified as vertex positions in either 32-bit float3 or 16-bit float3 values. There is also a stride property, so developers can tweak data alignment and use their rasterization vertex buffer, as long as it's HLSL float3, either 16-bit or 32-bit.
As for the tools to develop this in…
Microsoft announced PIX back in January 2017. This is a debugging and performance analyzer for 64-bit, DirectX 12 applications. Microsoft will upgrade it to support DXR as soon as the API is released (specifically, “Day 1”). This includes the API calls, the raytracing pipeline resources, the acceleration structure, and so forth. As usual, you can expect Microsoft to support their APIs with quite decent – not perfect, but decent – documentation and tools. They do it well, and they want to make sure it’s available when the API is.
Example of DXR via EA's in-development SEED engine.
In short, raytracing is here, but it’s not taking over rasterization. It doesn’t need to. Microsoft is just giving game developers another, standardized mechanism to gather supplementary data for their games. Several game engines have already announced support for this technology, including the usual suspects of anything top-tier game technology:
- Frostbite (EA/DICE)
- SEED (EA)
- 3DMark (Futuremark)
- Unreal Engine 4 (Epic Games)
- Unity Engine (Unity Technologies)
They also said, “and several others we can’t disclose yet”, so this list is not even complete. But, yeah, if you have Frostbite, Unreal Engine, and Unity, then you have a sizeable market as it is. There is always a question about how much each of these engines will support the technology. Currently, raytracing is not portable outside of DirectX 12, because it’s literally being announced today, and each of these engines intend to support more than just Windows 10 and Xbox.
Still, we finally have a standard for raytracing, which should drive vendors to optimize in a specific direction. From there, it's just a matter of someone taking the risk to actually use the technology for a cool work of art.
If you want to read more, check out Ryan's post about the also-announced RTX, NVIDIA's raytracing technology.
Rayly curious to see it in
Rayly curious to see it in action. I wonder what the performance hit for something like this would be.
We probably won’t get to fully raytraced games anytime soon, not after seeing how much horsepower Quake 2 raytraced needs. But it’s a small step in what I am hoping is the right direction, and not another dead end.
Edit:
Looks like Remedy posted a video of it running.
https://youtu.be/70W2aFr5-Xk
Looks like this can make use
Looks like this can make use of all those extra shader cores on AMD’s Vega 56/64 SKUs but I’m more interested in seeing what the Khronos will make use of in Vulkan to compete with this. AMD has some nice plugins for Blender/other graphics software and that implies usage for gaming engines also.
The Vega 56 has the exact number of shader cores as the GTX 1080Ti with the Vega 64 having loads more shader cores than the Vega 56.
and with all that money you
and with all that money you saved with that gpu you can also save even more money with game price drop as wait 3-6 months after release to play “the way it wasn’t meant to be played” version.
one speculative response deserves another
Who gives a f–k about GPUs
Who gives a f–k about GPUs for gaming, that’s for the basement dwellers, GPUs are for graphics and who cares about dirty filthy sloppy gaming FPS on non gaming graphics workloads.
That’s why I always get a big LOL when gamers are always screaming about AMD’s OpenGL performance in games as AMD’s OpenGL drivers are for professional CAD/Graphics workloads.
It’s not about gaming for AMD’s OpenGL. For non gaming graphics it’s about gettng more Rays Calculated and FPS is not as important as accuracy and fidelity.
Get the F-ING Mesa OpenGL drivers gamers and wallow in the FPS slop as I’m only caring about getting the most Ray Tracing Interaction Calcualtions done and the more Shader Cores the better.
i dont think programmers will
i dont think programmers will absorb this new tech. even though this deals with gpu. programmers are still using single cores up to 4 cores thanks to intel.
First off, programmers don’t
First off, programmers don’t typically develop for a set number of GPU cores. It just happens that games in particular do not scale well. The majority of the work that does was pushed to GPUs decades ago.
Second, GPUs entire thing is dealing with massively parallel workloads.
Parallel GPU workloads should
Parallel GPU workloads should perform better on AMD cards. Yet Nvidia are holding their own. How is this possible ? Also, parallel GPU’s require the game developer to tailor the game to the GPU architecture not the other way around. Yet the majority of games are poorly optimised for this. CEO’s want to take the profits first and not worry about the consequences. There is too much emphasis on how a game looks rather than functionality.
HUH?
Roughly speaking the CPU
HUH?
Roughly speaking the CPU breaks up a game like this:
1) Main thread of code (run on one core only), and
2) Branching threads of code (run on all cores/threads potentially depending on how threaded the game is)
RAY TRACING would simply be a branching thread of code on the CPU that makes requests to the graphics card.
So I don’t know what the “up to 4 cores thanks to Intel” even means in this context. Plus the lack of threading on more cores is NOT Intel’s fault in the slightest it’s simply a reflection of how hard it is to do multi-threading in games.
Ray Tracing is also a huge deal though it will be SLOW to come in so don’t get too excited in the short term. We should see something incredible in the next-gen consoles and a few games/demos with this in the next couple years.
This is NOT going to be full ray-tracing but rather a little mixed in with rasterization just like we get PhysX smoke or other effects merged in so the games must be playable WITHOUT the extra eye candy.
*LONG TERM you can expect games to be eventually FULL RAY-TRACED. So we’ll get a little more ray-tracing proportionality as newer GPU’s are released until finally the hardware can handle full 4K, 60FPS+ ray-tracing.