Monday, July 1st 2019
AMD Patent Shines Raytraced Light on Post-Navi Plans
An AMD patent may have just shown the company's hand when it comes to its interpretation of raytracing implementation on graphics cards. The patent, titled "Texture Processor Based Ray Tracing Acceleration Method and System", describes a hybrid, software-hardware approach to raytracing. AMD says this approach improves upon solely hardware-based solutions:
Essentially, AMD will be introducing what it calls a "fixed function ray intersection engine", which is specialized hardware that only handles BVH intersection (processing BVH calculations in a stream processor solely via a software solution isn't a pretty option, since execution divergence means that a number of error corrections are required, which makes the process time and resource-intensive). This fixed function hardware (which is nothing like NVIDIA's RT cores and is much simpler) is added in parallel to the texture filter pipeline in GPU's texture processor.
The idea is that the fixed-function raytracing hardware can now use the texture system's already existing memory buffers instead of having to store raytracing-specific data locally, which adds to die area and chip complexity. Additionally, since there is no software to allocate resources and schedule work for the fixed-function hardware, pure hardware solutions require an additional hardware scheduler only for RT-specific workloads, which AMD claims its implementation bypasses - the shader processor sends raytracing data down the texture processing path for the fixed-function hardware to process, saving even more die space that would be used in a "classical" hardware solution.
It's pretty well-known that both Sony and Microsoft's next-gen consoles will support raytracing, and will be AMD Navi-based in nature. It's likely these custom chips have some more of the special dust from AMD's RDNA architecture (which is only sprinkled on consumer, PC-level Navi), and these special components certainly pertain (even if not completely) to both consoles' raytracing capabilities. While the patent has been submitted a year and a half ago, this is the time to reap fruits from such a hybrid design; Some highlights on AMD's approach that have been taken from the paper can be seen below, but if you fancy a read of the whole patent, follow the source link.
Sources:
AMD Patent Application, via DSO Gaming
"The hybrid approach (doing fixed function acceleration for a single node of the bounded volume hierarchy (BVH) tree and using a shader unit to schedule the processing) addresses the issues with solely hardware based and/or solely software based solutions. Flexibility is preserved since the shader unit can still control the overall calculation and can bypass the fixed function hardware where needed and still get the performance advantage of the fixed function hardware. In addition, by utilizing the texture processor infrastructure, large buffers for ray storage and BVH caching are eliminated that are typically required in a hardware raytracing solution as the existing vector general purpose register (VGPRs) and texture cache can be used in its place, which substantially saves area and complexity of the hardware solution."
It's pretty well-known that both Sony and Microsoft's next-gen consoles will support raytracing, and will be AMD Navi-based in nature. It's likely these custom chips have some more of the special dust from AMD's RDNA architecture (which is only sprinkled on consumer, PC-level Navi), and these special components certainly pertain (even if not completely) to both consoles' raytracing capabilities. While the patent has been submitted a year and a half ago, this is the time to reap fruits from such a hybrid design; Some highlights on AMD's approach that have been taken from the paper can be seen below, but if you fancy a read of the whole patent, follow the source link.
The system includes a shader, texture processor (TP) and cache, which are interconnected. The TP includes a texture address unit (TA), a texture cache processor (TCP), a filter pipeline unit and a ray intersection engine. The shader sends a texture instruction which contains ray data and a pointer to a bounded volume hierarchy (BVH) node to the TA. The TCP uses an address provided by the TA to fetch BVH node data from the cache. The ray intersection engine performs ray-BVH node type intersection testing using the ray data and the BVH node data. The intersection testing results and indications for BVH traversal are returned to the shader via a texture data return path. The shader reviews the intersection results and the indications to decide how to traverse to the next BVH node.
(...)
A texture processor based ray tracing acceleration method and system are described herein. A fixed function BVH intersection testing and traversal (a common and expensive operation in ray tracers) logic is implemented on texture processors. This enables the performance and power efficiency of the ray tracing to be substantially improved without expanding high area and effort costs. High bandwidth paths within the texture processor and shader units that are used for texture processing are reused for BVH intersection testing and traversal. In general, a texture processor receives an instruction from the shader unit that includes ray data and BVH node pointer information. The texture processor fetches the BVH node data from memory using, for example, 16 double word (DW) block loads. The texture processor performs four ray-box intersections and children sorting for box nodes and 1 ray-triangle intersection for triangle nodes. The intersection results are returned to the shader unit.
In particular, a fixed function ray intersection engine is added in parallel to a texture filter pipeline in a texture processor. This enables the shader unit to issue a texture instruction which contains the ray data (ray origin and ray direction) and a pointer to the BVH node in the BVH tree. The texture processor can fetch the BVH node data from memory and supply both the data from the BVH node and the ray data to the fixed function ray intersection engine. The ray intersection engine looks at the data for the BVH node and determines whether it needs to do ray-box intersection or ray-triangle intersection testing. The ray intersection engine configures its ALUs or compute units accordingly and passes the ray data and BVH node data through the configured internal ALUs or compute units to calculate the intersection results. Based on the results of the intersection testing, a state machine determines how the shader unit should advance its internal stack (traversal stack) and traverse the BVH tree. The state machine can be fixed function or programmable. The intersection testing results and/or a list of node pointers which need to be traversed next (in the order they need to be traversed) are returned to the shader unit using the texture data return path. The shader unit reviews the results of the intersection and the indications received to decide how to traverse to the next node in the BVH tree.
55 Comments on AMD Patent Shines Raytraced Light on Post-Navi Plans
Ray tracing is useless now btw whit it's DLSS feature. You can have it and yet you can't play it properly because of the performance impact. What's the point of having it anyway.
It is good that it is there and maybe at some point you will be able to play 2k with RT on with a card for a reasonable price but not this year or next my friend.
They are, in fact, FUNDING research and development at AMD.
Whatever comes out, will be used in other products.
Obviously, it's not done yet, to appear in products that will be released in 5 days.
As for waiting... Wait and see if RT is used in consoles first. But then it's quite a long wait.
As AMD's BHV trees are flexible, unlike nvidia's, one might discover that NV's implementation struggling with whatever comes later.
No point to "wait", anyhow.$380 5700 is obsolete, because nVidia will release 2060Super, that will be as fast, and cost $20 more.
An illustration to: "what's wrong with green brains".
tpucdn.com/review/sapphire-rx-570-pulse/images/perfrel_1920_1080.png
And yeah, AMD has a CPU to offer too which would for sure means even cheaper prices.
AMD can take strange brigade game as a benchmark and make NV lack performance. Is that the way to go? I don't think so. Larger spectrum of games is needed to more less evaluate the performance and value of given card not just one game. Not saying it shouldn't be in a mix.
RT and DLSS work from 2 different pieces of hardware on the card. DLSS, though typically with a small negative IQ impact, helps boost FPS back up with RT adds the reflections.
What is thought of it is a different story. But with AMD coming out with what amounts to the same thing, it hardly useless.
I love how NVIDIA (read: any company) gets shit on for being an innovator.
For example, lets say RX570 gets 82.5 and RX580 gets 91.1 fps at 1080p in Strange Brigade. That makes RX580 10% faster in this game at this resolution. This might be enough to suspect this might be the case in general. Based on this, knowing that RX570 and GTX1060 3GB are roughly equal we may conclude that RX580 should be that ~10% faster. In this case the eventual performance difference across many games in the same review ends up being slightly larger at 13%. You can see that GTX1060 3GB is 20% slower than RX570 in Strange Brigade but this is irrelevant in the comparison we are making.
The final truth will be there when NDAs are gone and reviews are out but until then we only have incomplete data to analyze and try to make educated guesses from :)
It's MATH. Nothing more. First algorhytms appeared late 60's, improvements later.
It's nothing 'invented' by nvidia or amd - CPUs did it in old versions of 3d studio (then, now MAX) and other animation software.
So, there's like nothing holding up 'implementation' of ray-tracing, mental-ray, radiosity - name the rendering type ever for any GPU (or CPU) - question is just how successful it will be in it.
There's also no 'magical' ray-tracing hardware or software improvements.
nvidia/comments/baaqb0