AMD Allegedly Has a Patent for Its Ray Tracing Solution

[cageymaru]

Patent is found here. I would skip to page 22 after reading the opening statement.

 

[IdiotInCharge]

One would hope... otherwise, by the time they caught up, they'd be crowded out of the GPU market by Intel.

 

[gwarren007]

Patent is found here. I would skip to page 22 after reading the opening statement.

TL: DR - Cliffs?

 

[Grimlaking]

So in essence instead of specific Ray Tracing cores similar to what Nvidia is doing. AMD is claiming if I am reading this correctly a new sort of core design that can do both texture rendering and ray tracing for active rays in a wave.

So each wave contains active and inactive waves that need to be processed... And they are done based on if the rays within the wave are active. And if so the same Processor unit that processes textures is capable in the same pass as processing the active Ray within the wave.

Meaning... they added another code path to the simple core design of the texture processor. Making it more of a GPU that a task specific processor. This means they can theoretically be more flexible with code that wants ray tracing. And deliver ray tracing performance as well at the cost of power/TDP. BUT it may suffer from raw performance compared to a separate pipeline for doing Ray Tracing processing alone.

The statement about performance is mien alone based on previous examples of multi task CPU's not being as fast as dedicated cores designed to do something. Of course the additional flexibility is what you get for that and having to spend less die space to get Ray Tracing. So if they get more of these new general GPU units in a die then they increase raw non Ray Trace performance, AND have the ability to do ray tracing as well. The cost is in the raw throughput. It is too early to say if this will be the big win or not.

I remember when 3d cards were a new thing. They were separate cards until they figured out how to put it all on one card. Now the tell will be how it runs all on one "graphics processing unit" as opposed to a separate Ray Tracing Processor.

The summary begins in Page Five bottom right under "What is Claimed is:"

The other question is how far off is this... and was AMD worried Nvidia would do this.

By laying this claim Nvidia is now prevented or has to be more careful if they introduce a die that can do Texture AND Ray tracing in the same compute unit.

I am neither a legal or processor designer so the above is opinion based on what I could derive from the published document. Nothing more nothing less. I suggest you read the same section and see if you agree.

 

[funkydmunky]

Being it is part of DX12 spec is a patent needed or only if they are going about it in a unique way in which they don't want a competitor copying?

 

[sirmonkey1985]

Being it is part of DX12 spec is a patent needed or only if they are going about it in a unique way in which they don't want a competitor copying?

the software is dx12 spec, the hardware in which to make it function is proprietary, nvidia patented RT cores as well.

 

[cyklondx]

can do both texture rendering and ray tracing for active rays in a wave.

that's part of the design structure of the vega shader arch described in vega whitepapers aka. Primitive Shaders, and NCU processing HDR content.

 

[Snowdog]

So in essence instead of specific Ray Tracing cores similar to what Nvidia is doing. AMD is claiming if I am reading this correctly a new sort of core design that can do both texture rendering and ray tracing for active rays in a wave.

Not my reading at all. It's incredible similar to what NVidia is doing. They refer to the "Ray Intersection Engine" doing the intersection testing. This is analogous to NVidia RT cores.

But the "Ray Intersection Engine" is not described, and is not subject of the patent. The patent describes the how the communication happens between the shader cores and the "Ray Intersection Engine" contained in the Texture processor.

Again that communication happens very similar to how NVidia describes theirs, and the difference is likely some subtle nuance that lets them have separate patents.

Again, my reading is that the "Ray Intersection Engine" is specific HW, that does the same job as "RT Cores". The real question, is does Navi already have "Ray Intersection Engine" in it's Texture processor units? It does seem to use a lot of transistors for the Raster perforrmance claimed.

They might have been able to design in the "RIE" but will need time to work out all the SW interactions to get Ray Tracing working well, and they will keep it quiet until they are really ready this time. No announcing features that never seem to work like with Vega.

 

[GoodBoy]

What this really means is that they are taking Ray Tracing seriously.

They have to have a patent with a "slightly different process" so that nVidia doesn't sue them for possibly copying something. There's likely not all that much "intellectual property" in either nVidia's or AMD's ray tracing, other than the layout of the processing channels and maybe some software that works with the specific hardware layout. But they both patent it to protect themselves from patent trolls and outright design theft/copying.

 

[Grimlaking]

Not my reading at all. It's incredible similar to what NVidia is doing. They refer to the "Ray Intersection Engine" doing the intersection testing. This is analogous to NVidia RT cores.

But the "Ray Intersection Engine" is not described, and is not subject of the patent. The patent describes the how the communication happens between the shader cores and the "Ray Intersection Engine" contained in the Texture processor.

Again that communication happens very similar to how NVidia describes theirs, and the difference is likely some subtle nuance that lets them have separate patents.

Again, my reading is that the "Ray Intersection Engine" is specific HW, that does the same job as "RT Cores". The real question, is does Navi already have "Ray Intersection Engine" in it's Texture processor units? It does seem to use a lot of transistors for the Raster perforrmance claimed.

They might have been able to design in the "RIE" but will need time to work out all the SW interactions to get Ray Tracing working well, and they will keep it quiet until they are really ready this time. No announcing features that never seem to work like with Vega.

I'm curious what section you are referring to. they specifically make claims earlier in the document that dedicated hardware 'cores' to do ray tracing are costly and too fixed in implementation. (Basically a dig at Nvidia's RT cores.)

Then later describe a core that has logic for Texture rendering and Ray Tracing which is what this document is designed to protect the IP of.

I'm just curious where I missed the boat. Or are you talking about a processor to assign the different threads to cores?

 

[Snowdog]

I'm curious what section you are referring to. they specifically make claims earlier in the document that dedicated hardware 'cores' to do ray tracing are costly and too fixed in implementation. (Basically a dig at Nvidia's RT cores.)

That is the section where they list pros and cons of both HW and SW. Later they go on to say:

"A fixed function BVH intersection testing and traversal (a common and expensive operation in ray tracers) logic is implemented on texture processors. "

So clearly they are implementing the fixed function HW in the texture processor, to do Ray intersection testing, which is exactly what NVidia does in its fixed function RT cores.

It's essentially the same thing. They seem to claim that they do some other communications and overhead in SW to save die area, but really that is a subtle distinction from the way NVidia does it with it's RT cores, and or course there are no Tensor cores.

 

[Armenius]

that's part of the design structure of the vega shader arch described in vega whitepapers aka. Primitive Shaders, and NCU processing HDR content.

So it will need to be coded specifically for AMD's solution? How well is that working out with primitive shaders?

 

[cyklondx]

So it will need to be coded specifically for AMD's solution? How well is that working out with primitive shaders?

As far as I understand this is only overview of what is happening inside the shader, and physically on gpu. I have no idea how they are working as it was on developers to program them on vega cards; and they (amd) never have enabled them in drivers (as far as i know).

 

[ChadD]

Being it is part of DX12 spec is a patent needed or only if they are going about it in a unique way in which they don't want a competitor copying?

DX12 Vulkan OpenGL... are just high level code compilers. Programmers can pass data on to be processed but they don't have to know what is going on behind the curtain at the hardware level. Just like someone programming in C or Java ect doesn't have to know what the intel or amd chip is doing... the use the bit of their coding language that defines a variable and say in the high level language. Pull this value and this value add them together and save it as variable X. ect ect.

DX12 ray tracing is high level... game developers aren't telling the GPU to specifically do anything. They are saying I want to calculate this and this and create same rays and use the output to refine my lighting or create relection ect. Their compiled code then talks to the driver and says hey driver the hardware needs to do X Y and Z.

AMD is doing something a bit unique it seems... and if I read it right it sounds like pretty much I expected when they detailed the RDNA arch and its ability to calculate at wave32. It sounds to me (and we'll see what it all really means down the road) that AMD is planning to use regular shaders however they have included a mode in RDNA that allows each shader to operate at wave32x2 instead of wave64 (the normal method every card until now has done) For ray calculation you don't need 64bit address space... 32 bit will do. So if AMD was to use this method it means that in one clock instead of using one shader to calculate a ray... they could calculate 2. To go a little further AMD I believe also claimed RDNA is clustering shaders and running twice as many per clock already.... so I believe it would be more like each clock would calculate a max 4 bits of data per wave32 each clock cycle. Meaning RDNA cards doing tracing in shaders could potentially be up to 4x faster then older non RDNA cards using shaders.

Right now the 1080 class hardware can almost match the low end RTX cards doing ray tracing in shader space. IF AMDs RDNA is capable of massively upping the amount of ray type math they can do per shader clock... its possible they could equal NVs RTX parts without anything "special" other then the updated shader arch. Guess we'll find out next year unless AMD has some reason to talk about it sooner.

 

[Nolan7689]

That’s rather interesting. Most of it all is way above my head but if ChadD is on the right track that could be an impressive method of providing ray tracing. Without the additional die size and cost of specialized cores.

 

[Snowdog]

That’s rather interesting. Most of it all is way above my head but if ChadD is on the right track that could be an impressive method of providing ray tracing. Without the additional die size and cost of specialized cores.

As usual, he isn't.

In this patent, AMD is stating directly that their proposed solution is using their own fixed Function "RT core" equivalent parts to calculate intersections.

But he doesn't believe NVidia when they state they have fixed function RT cores, so why would he believe AMD when they also state it.

The main differences appear to be the location of the "RT Cores" and the communications path with the Shaders.

 

[Grimlaking]

As usual, he isn't.

In this patent, AMD is stating directly that their proposed solution is using their own fixed Function "RT core" equivalent parts to calculate intersections.

But he doesn't believe NVidia when they state they have fixed function RT cores, so why would he believe AMD when they also state it.

The main differences appear to be the location of the "RT Cores" and the communications path with the Shaders.

It looks to me like the Texture processor and the RAY 'processor' are one in the same on the card utilizing a shared memory space/cache.

Maybe you didn't get to the end of the article.

Please quote me where they say they are separate. I'd love to see that if I missed it.

 

[IdiotInCharge]

Please quote me where they say they are separate. I'd love to see that if I missed it.

They're not separate, i.e. on another part of the die as RTX cores are, but they are fixed-function hardware meaning that there's a separate path in each core for ray intersection.

Basically, as opposed to bulding a separate island of circuitry on the die for ray tracing, AMD distributed this circuitry among the traditional shader cores.

AMD is probably ahead of Nvidia here in terms of how ray tracing should be implemented, i.e. it should be part of the basic pipeline that all processing flows through, but both approaches make sense. Nvidia's hardware segmentation of RTX cores is likely the result of earlier and thus less clear planning that allowed them some flexibility later in the production schedule. AMD's implementation is likely newer and more informed, so they had a potentially better idea of what mix of resources might be needed, and this mix is likely tuned for how ray tracing is expected to be used in the upcoming console generation.

 

[Snowdog]

View attachment 170833

It looks to me like the Texture processor and the RAY 'processor' are one in the same on the card utilizing a shared memory space/cache.

Please quote me where they say they are separate. I'd love to see that if I missed it.

Maybe you didn't get to the end of the patent, because it is very clear if you take the time to read and understand the connection between the claims, and the details that follow.

They aren't separate. The texture processor contains AMD's "RT Core" equivalent. Much like NVidias SM's contain the RT cores. The RT cores are in different places, but same fixed function RT type cores.

You are quoting "Claim 20" talking about texture processor, note that they state "The Texture processor of Claim 19". So go read "Claim 19" to see what that Texture process contains:

"Claim 19:. A texture processor comprising: a texture address unit connected to a shader; a texture cache connected to the texture address unit; a ray intersection engine connected to the texture address unit, the texture cache and the shader; wherein: the texture address unit is configured to: receive from the shader a texture instruction which includes at least a bounded volume hierarchy (BVH) node pointer and ray data; filter the texture instruction to obtain the ray data; fetch BVH node data from the texture cache based on the BVH node pointer, the ray intersection engine is configured to: receive the ray data and the BVH node data; perform ray-BVH node type intersection testing using the ray data and the BVH node data; and send intersection results based on the ray-BVH node type intersection testing via a texture data return path to the shader."

The "Ray Intersection Engine" is AMDs equivalent of NVidia "RT cores".

Now it isn't described in detail in the claims section, but further below in the DETAILED DESCRIPTION section:

"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."

"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."


Did you read it? It's all over the place. It should be unmistakable.

AMD is adding fixed function "Ray Intersection Engine" to their texture unit. Read what their fixed function unit does and go read what NVidia RT cores do. It's the same operation. It's the most expensive part of Ray Tracing and the part you really need dedicated HW if you are going to tackle this problem.


None of this should surprise anyone. Something like dedicated RT cores are required.

It does open the possibility that maybe Navi already has the "RIE" added to Navi, and they need time to get the Software parts all working together for a nice reveal later.

 

[Grimlaking]

Yes... much like the various specialized paths in a general AMD or Intel CPU as I stated in my more detailed response earlier in this thread. It is another path introduced in the same Processor.

IE not a separate entity on the die itself but directly integrated into the logic of the Texture processor.

Please stop trying to sound like you're covering new ground. You're not.

They are NOT dedicated RT Cores. It is simply a specialized logic path on the Texture processor. This is not a unique methodology to add new function to a CPU.

You build in paths to accelerate specific types of processing. It makes sense. To see what one functions better in the real world will be the proof in the pudding.

As a case in point go to this URL: https://ark.intel.com/content/www/u...9700k-processor-12m-cache-up-to-4-90-ghz.html

Go down to the advanced functions that are on the i7 chip in the example. THESE are the same basic logic as adding the Ray Tracing function to the Texture Processor. Yes it makes that processor a bit more complicated and adds a level of gating that wasn't there before. But the overall should be better? As I said above in this post seeing it in the real world will be the difference.

 

[Snowdog]

Yes... much like the various specialized paths in a general AMD or Intel CPU as I stated in my more detailed response earlier in this thread. It is another path introduced in the same Processor.

IE not a separate entity on the die itself but directly integrated into the logic of the Texture processor.

Please stop trying to sound like you're covering new ground. You're not.

They are NOT dedicated RT Cores. It is simply a specialized logic path on the Texture processor. This is not a unique methodology to add new function to a CPU.

You build in paths to accelerate specific types of processing. It makes sense. To see what one functions better in the real world will be the proof in the pudding.

As a case in point go to this URL: https://ark.intel.com/content/www/u...9700k-processor-12m-cache-up-to-4-90-ghz.html

Go down to the advanced functions that are on the i7 chip in the example. THESE are the same basic logic as adding the Ray Tracing function to the Texture Processor. Yes it makes that processor a bit more complicated and adds a level of gating that wasn't there before. But the overall should be better? As I said above in this post seeing it in the real world will be the difference.

Hey, you asked, I can't help it, if the topic is over your head.

But it is very clear that AMDs "fixed function ray intersection engine" = NVidias "RT Core".

The are both dedicated HW, and they both accelerate exactly the same operations.

 

[Gideon]

I will care more when I can see how it actually performs the rest really doesn't matter.

 

[Hagrid]

I will care more when I can see how it actually performs the rest really doesn't matter.

This. Right now it's all still young and needs a few more years. No hurry.

 

[sharknice]

I wonder what the developers for the next gen xbox and PlayStation 5 are doing since AMD raytracing doesn't exist yet. If any games are planning on launching with raytracing they're probably ironically developing using Nvidia hardware right now, until this becomes available.

 

[ChadD]

As usual, he isn't.

In this patent, AMD is stating directly that their proposed solution is using their own fixed Function "RT core" equivalent parts to calculate intersections.

But he doesn't believe NVidia when they state they have fixed function RT cores, so why would he believe AMD when they also state it.

The main differences appear to be the location of the "RT Cores" and the communications path with the Shaders.

A shader core IS aaa fixed function compute unit.

A Ray intersection unit can be nothing more then a header adress space defining data moving through the RDNA shader cluster denoting it as a wave32 function that needs accesss to X pool of cache being used for ray calculation.

Believe it or not I do have a pretty good idea how this stuff works. lol I am also not claiming I am without a doubt 100% correct. It is how it reads to me... a semi informed mostly lay person.

Until AMD announces a product. This is nothing but interesting reading. (and NV is the only compnay selling consumer real time ray tracing anything) I don't think they are releasing a big version of Navi with a completely different layout. I could however be completely wrong. We'll know down the road.

 

[IdiotInCharge]

I wonder what the developers for the next gen xbox and PlayStation 5 are doing since AMD raytracing doesn't exist yet. If any games are planning on launching with raytracing they're probably ironically developing using Nvidia hardware right now, until this becomes available.

It doesn't exist on a discrete GPU, but I'm betting AMD has developer units for function checking, even if they are borged versions of current retail releases. They really have to have them out given that ray tracing even with good hardware needs to be applied intelligently (i.e., not BF:V), and sparingly in the case of consoles.

 

[ChadD]

I wonder what the developers for the next gen xbox and PlayStation 5 are doing since AMD raytracing doesn't exist yet. If any games are planning on launching with raytracing they're probably ironically developing using Nvidia hardware right now, until this becomes available.

Or Sony/MS/AMD have a developer driver for a MI60 or RadeonVII/Vega that enables shader based tracing. It might not run at 200FPS or anything... but it would likely run as well as the 1080 does... which might be sufficent to do development work. I found the Crytek vega56 ray tracing demo interesting.... I have a feeling AMD didn't know nothing of thier work. Or you might be correct. lol

EDIT Sniped by IIC.