ID buffer and DR FP16

[AlNom]

Hardware that assists in CB doesn't automatically equate to ID Buffer etc. since CB is not a singular implementation.

 

[Shifty Geezer]

I'm sure Xbox One X has ID buffer feature in the gpu states in DF Scorpio reveal. Who says it doesn't?

As I understand it, the ID Buffer was a Sony invention/request. It may appear in future AMD designs but there's nothing to suggest the idea was around for XBOX development or that MS have permission to use Sony's design.
http://www.eurogamer.net/articles/d...tation-4-pro-how-sony-made-a-4k-games-machine

Right now, post-process anti-aliasing techniques like FXAA or SMAA have their limits. Edge detection accuracy varies dramatically. Searches based on high contrast differentials, depth or normal maps - or a combination - all have limitations. Sony had fashioned its own, highly innovative solution.

"We'd really like to know where the object and triangle boundaries are when performing spatial anti-aliasing, but contrast, Z [depth] and normal are all imperfect solutions," Cerny says. "We'd also like to track the information from frame to frame because we're performing temporal anti-aliasing. It would be great to know the relationship between the previous frame and the current frame better. Our solution to this long-standing problem in computer graphics is the ID buffer. It's like a super-stencil. It's a separate buffer written by custom hardware that contains the object ID."

Slightly ambiguous, but to date only Sony have talked about an ID buffer. I don't know of any related patents - you'd think someone would have one, AMD or Sony.

 

[3dilettante]

According to this GAF post, there are 2 others custom hardware features on Pro:

*image snipped*

And apparently this feature, "texture gradient adjustement" has being patented by Mark Cerny with the name:

Gradient adjustment for texture mapping to non-orthonormal grid

Could those 2 new features be part of future AMD Navi features ? Even "Texture gradient adjustement" because of the patent ?

Gradient adjustment per a later slide allows the hardware to optimize manual work needed to correct for sampling that originally assumes the traditional square pixel quad, which winds up being stretched into a rectangle in a CB scheme using Sony's reference or a sparse method that does something similar. The ALU consumed by fix-up math, more expensive sampling, and registers storing the derivatives used for the fix-up are listed as overheads, but I'm a little unclear on whether the PS4's optimization does more than optimize away the ALU component without affecting the other two. The cycle cost of the sampling might still be higher if there's more calculation overhead within the texture address unit. If the correction is stored in the texture unit, I'm wondering if the register storage could be reclaimed after the matrix is calculated once and sent to the unit (if that's what Sony's method does).

If DICE's presentation is a guide, it's a modest ALU savings at least. If the specific adjustment in DICE's presentation is actually built into the operation of the pipeline, then there are potentially savings built into the other two areas of overhead. However, that would indicate the customization is rather specific. If more programmable than that, the exact limits aren't shown. Different or more complicated adjustments to texture address calculations might exceed the storage or practically usable ALU/scheduling resources in the texture unit.

That might fly for a console, but AMD's original discussions about GCN showed they were originally hoping to reduce the amount of hidden state in the texture pipeline, since that was one of the remaining areas that wasn't cleanly exposed in the compute-oriented architecture. However, whether that original goal remains is unclear.

Given the modest improvement, AMD's more general PC environment might find it too specific, and the long-term goal to someday remove black-box functionality from the CU would not be served by having yet more context stored in the pipeline in a future GPU.

 

[iroboto]

As I understand it, the ID Buffer was a Sony invention/request. It may appear in future AMD designs but there's nothing to suggest the idea was around for XBOX development or that MS have permission to use Sony's design.
http://www.eurogamer.net/articles/d...tation-4-pro-how-sony-made-a-4k-games-machine

Slightly ambiguous, but to date only Sony have talked about an ID buffer. I don't know of any related patents - you'd think someone would have one, AMD or Sony.

I think Arc is referring to this piece from DF

Microsoft didn't delve too deeply into specifics on the checkerboarding support that Scorpio possesses at the hardware level. However, Andrew Goossen tells us that the GPU supports extensions that allow depth and ID buffers to be efficiently rendered at full native resolution, while colour buffers can be rendered at half resolution with full pixel shader efficiency. Based on conversations last year with Mark Cerny, there is some commonality in approach here with some of the aspects of PlayStation 4 Pro's design, but we can expect some variation in customisations - despite both working with AMD, we're reliably informed that neither Sony or Microsoft are at all aware of each other's designs before they are publicly unveiled.

* See bolded as a supplement to your commentary.

http://www.eurogamer.net/articles/digitalfoundry-2017-the-scorpio-engine-in-depth

Not sure what that entails, they don't seem to have any more information out there that discusses it. The thing is, when i read "GPU supports extensions", I'm not necessarily reading it as hardware support in my mind. I just read an API that will emulate 'ID buffer' behaviour for you; maybe that's a poor interpretation on my behalf.

 

[MrFox]

Slightly ambiguous, but to date only Sony have talked about an ID buffer. I don't know of any related patents - you'd think someone would have one, AMD or Sony.

Patent from sony...
https://www.google.com/patents/US9710957

Interrelated to many other patents:

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to commonly-assigned, co-pending U.S. patent application Ser. No. 14/246,064, to Tobias Berghoff, entitled “METHOD FOR EFFICIENT CONSTRUCTION OF HIGH RESOLUTION DISPLAY BUFFERS”, filed the same day as the present application, the entire contents of which are herein incorporated by reference.

This application is related to commonly-assigned, co-pending U.S. patent application Ser. No. 14/246,068, to Mark Evan Cerny, entitled “GRADIENT ADJUSTMENT FOR TEXTURE MAPPING TO NON-ORTHONORMAL GRID”, filed the same day as the present application, the entire contents of which are herein incorporated by reference.

This application is related to commonly-assigned, co-pending U.S. patent application Ser. No. 14/246,061, to Tobias Berghoff, entitled “VARYING EFFECTIVE RESOLUTION BY SCREEN LOCATION BY CHANGING ACTIVE COLOR SAMPLE COUNT WITHIN MULTIPLE RENDER TARGETS”, filed the same day as the present application, the entire contents of which are herein incorporated by reference.

This application is related to commonly-assigned, co-pending U.S. patent application Ser. No. 14/246,063, to Mark Evan Cerny, entitled “VARYING EFFECTIVE RESOLUTION BY SCREEN LOCATION BY ALTERING RASTERIZATION PARAMETERS”, filed the same day as the present application, the entire contents of which are herein incorporated by reference.

This application is related to commonly-assigned, co-pending U.S. patent application Ser. No. 14/246,066, to Mark Evan Cerny, entitled “VARYING EFFECTIVE RESOLUTION BY SCREEN LOCATION IN GRAPHICS PROCESSING BY APPROXIMATING PROJECTION OF VERTICES ONTO CURVED VIEWPORT”, filed the same day as the present application, the entire contents of which are herein incorporated by reference.

This application is related to commonly-assigned, co-pending U.S. patent application Ser. No. 14/246,062, to Mark Evan Cerny, entitled “GRADIENT ADJUSTMENT FOR TEXTURE MAPPING FOR MULTIPLE RENDER TARGETS WITH RESOLUTION THAT VARIES BY SCREEN LOCATION”, filed the same day as the present application, the entire contents of which are herein incorporated by reference.

 

[Shifty Geezer]

Of course, it was our own TB. I remember now. So basically Sony owns the patent on an ID buffer and MS can't use it bar patent wrangling.
(Why do patents feel the need to use the word 'plurality'? It's not used anywhere else, where 'number' would suffice. Patents are so frickin' weird!)

 

[Jay]

it's a shame we don't actually know anything regarding the Scorpio engine IP.
i expect that there's no difference to base X1 apart from efficiency improvements.

that doesn't mean it's worse off not having RPM & ID Buffer. If adding them meant having an overall less performant chip, as may not have been able to make the same efficiency improvements.
so possible overall net plus, especially if the performance gains using ID Buffer isn't high compared to manually doing it

4Pro benefits are:

• RPM & ID Buffer from selfish point of view is interesting to me to how they will be used.
• engine research and development
• smart rendering development
• when ps5 comes out engines will already be using it

lots of these things can be done without ID Buffer, but having it helps focus and direction of engine research

 

[iroboto]

Of course, it was our own TB. I remember now. So basically Sony owns the patent on an ID buffer and MS can't use it bar patent wrangling.
(Why do patents feel the need to use the word 'plurality'? It's not used anywhere else, where 'number' would suffice. Patents are so frickin' weird!)

I'm not entirely sure of the degree of the reach of the patent. I don't believe that you can patent the buffer itself, I imagine that's just memory/cache. The way the hardware accesses that memory could be patented though.

 

[higherARC]

Hardware that assists in CB doesn't automatically equate to ID Buffer etc. since CB is not a singular implementation.

That is true it is possible that MS created their own hardware to handle ID buffers or could be hardware that works exactly the same

I guess GDC 2018 could tell

 

[MrFox]

I'm not entirely sure of the degree of the reach of the patent. I don't believe that you can patent the buffer itself, I imagine that's just memory/cache. The way the hardware accesses that memory could be patented though.

I am not well versed in patent-speak, but I think "method" applies to hardware and software as long as it's the same implementation from claim #1. Possibly easy to design a different method acheiving the same goal. It's the method to build an ID buffer and how it's used which is patented, not the id buffer itself.

The patent is always only the claim #1, everything else is just supporting explanations and context.

Hardware implementations are usually named "device or apparatus" or something.

 

[iroboto]

I am not well versed in patent-speak, but I think "method" applies to hardware and software as long as it's the same implementation from claim #1. Possibly easy to design a different method acheiving the same goal. It's the method to build an ID buffer and how it's used which is patented, not the id buffer itself.

The patent is always only the claim #1, everything else is just supporting explanations and context.

Hardware implementations are usually named "device or apparatus" or something.

Neither am I, I'm left to assume that, if you came up with your own method of doing the same thing, you wouldn't be patent infringing. Otherwise patent trolling would kill the world.

 

[Globalisateur]

I'm pretty sure that Pixel Shader Invocation Control has been in the PS4 since the beginning.

Notice the asterisk: "Pro custom hardware features". Interestingly you may be right, if this is already on PS4 the name DICE used on the slide for this Pro feature might not be quite right.

I think Arc is referring to this piece from DF

* See bolded as a supplement to your commentary.

http://www.eurogamer.net/articles/digitalfoundry-2017-the-scorpio-engine-in-depth

Not sure what that entails, they don't seem to have any more information out there that discusses it. The thing is, when i read "GPU supports extensions", I'm not necessarily reading it as hardware support in my mind. I just read an API that will emulate 'ID buffer' behaviour for you; maybe that's a poor interpretation on my behalf.

This is exactly how I read it. If there was some hardware customization, they would have said it already. Like what the customization they've done to the Jaguar, lower latency and such.

Gradient adjustment per a later slide allows the hardware to optimize manual work needed to correct for sampling that originally assumes the traditional square pixel quad, which winds up being stretched into a rectangle in a CB scheme using Sony's reference or a sparse method that does something similar. The ALU consumed by fix-up math, more expensive sampling, and registers storing the derivatives used for the fix-up are listed as overheads, but I'm a little unclear on whether the PS4's optimization does more than optimize away the ALU component without affecting the other two. The cycle cost of the sampling might still be higher if there's more calculation overhead within the texture address unit. If the correction is stored in the texture unit, I'm wondering if the register storage could be reclaimed after the matrix is calculated once and sent to the unit (if that's what Sony's method does).

If DICE's presentation is a guide, it's a modest ALU savings at least. If the specific adjustment in DICE's presentation is actually built into the operation of the pipeline, then there are potentially savings built into the other two areas of overhead. However, that would indicate the customization is rather specific. If more programmable than that, the exact limits aren't shown. Different or more complicated adjustments to texture address calculations might exceed the storage or practically usable ALU/scheduling resources in the texture unit.

That might fly for a console, but AMD's original discussions about GCN showed they were originally hoping to reduce the amount of hidden state in the texture pipeline, since that was one of the remaining areas that wasn't cleanly exposed in the compute-oriented architecture. However, whether that original goal remains is unclear.

Given the modest improvement, AMD's more general PC environment might find it too specific, and the long-term goal to someday remove black-box functionality from the CU would not be served by having yet more context stored in the pipeline in a future GPU.

Like better LOD of textures ?

 

[3dilettante]

Like better LOD of textures ?

I'm speaking to the unknown way the transformation is stored into and applied by the texture units. If it's hard-wired or part of internal firmware, there's a limited range or single way that the adjustment can be used, and deviating too far from the planned range means not using it.

If there's a more complex method of calculating and then storing the adjustments via software, perhaps a broader range of methods or custom behaviors could be exploited. It's just not clear from the slide what sort of compiler/hardware support this customization entails.

Hard-wired runs the risk of becoming outdated or too inflexible to be broadly useful. More flexible implementations may require hidden state in the texture pipeline, which AMD in the past said it wanted to get rid off. Whether something like this customization appears in later GPUs might depend on whether AMD's goals have changed.

 

[BRiT]

Notice the asterisk: "Pro custom hardware features". Interestingly you may be right, if this is already on PS4 the name DICE used on the slide for this Pro feature might not be quite right.

Yes, I noticed the incorrect asterisk. That's what caused me to respond saying otherwise.

 

[npoe]

I remember an interview with Raja maybe from the very first months of the year (possible during CES) in which he was saying that 8K would come to AMD not from TFLOPs but from using techniques as ID Buffer and CB. I tried to find the article/interview but I couldn't. The layout of the webpage was similar to HardOCP but I didn't find it there. If he is considering using ID Buffer for future AMD products then the patent from Sony is very specific or there is some sort of cross license deal.

Additionally I don't think that Xbox One X support ID Buffer at hardware (if it does) to the same extend that PS4 Pro does it. The focus during Scorpio development was to keep compatibility of older/current engines and improve performance to reach 4K. Adding new hardware that older/current game engines won't use is not what I would consider aligned to the primary objectives, now they might have done something to better support software based ID Buffer from older/current engines.

They didn't even got into details about CPU changes other than mentioning benefits even at their Hot Chips conference in August. I'm not sure how much we can take the lack of information as proof of no hardware improvements since in my opinion they are more secretive than the average tech company.

 

[iroboto]

I remember an interview with Raja maybe from the very first months of the year (possible during CES) in which he was saying that 8K would come to AMD not from TFLOPs but from using techniques as ID Buffer and CB. I tried to find the article/interview but I couldn't. The layout of the webpage was similar to HardOCP but I didn't find it there. If he is considering using ID Buffer for future AMD products then the patent from Sony is very specific or there is some sort of cross license deal.

Additionally I don't think that Xbox One X support ID Buffer at hardware (if it does) to the same extend that PS4 Pro does it. The focus during Scorpio development was to keep compatibility of older/current engines and improve performance to reach 4K. Adding new hardware that older/current game engines won't use is not what I would consider aligned to the primary objectives, now they might have done something to better support software based ID Buffer from older/current engines.

If I could offer another perspective on this one, and this mainly sort of falls in line with MS behaviour when it comes to graphics tech. If its something they think everyone will need in the future, they'll put it in Direct X. And while Max can provide greater input on the process, I'm going to assume that they describe the behaviour and cases of all API calls, and leave it to vendors to decide how to implement it and as long as you pass the cases, you're certified for that feature set.

That being said, Sony often goes ahead and does what it needs because it doesn't need to work with anyone else when it comes to their own tech. So I don't see a Sony cross AMD license deal. There's just no point if MS is putting the feature in DX12.X, the guidelines and behaviours and standards are there to follow, all they need to do is create the tech to meet the desired functionality.

So, if this is anywhere close to the truth, my assumption is that if Scorpio has ID Buffer tech, we are at least looking at preliminary WARP version of ID Buffer, possibly tier 1 or more hardware implementation. Where Sony has gone their own route entirely, it can probably be mapped back to DX12 tier levels, but since we don't know what they are/even exists we can't really speak to that.

tldr;
Nvidia had conservative rasterization on their hardware before it became a directX feature requirement. It's clear they could not patent conservative rasterization the behaviour, but they can patent how they implement it.

 

[scently]

I will quote myself again from a few pages back:

From what I recall in the DF Scorpio article, Scorpio does possess hardware support for checkerboard rendering and such. This is a quote in the article;
"Microsoft didn't delve too deeply into specifics on the checkerboarding support that Scorpio possesses at the hardware level. However, Andrew Goossen tells us that the GPU supports extensions that allow depth and ID buffers to be efficiently rendered at full native resolution, while colour buffers can be rendered at half resolution with full pixel shader efficiency."
"We are perfectly happy with developers choosing a bunch of other techniques that are possible. We have hardware techniques for making checkerboarding very efficient. If developers want to go for checkerboarding, that's great. We've also heard from a bunch of our partners that they're actually finding that they prefer TAA [temporal anti-aliasing] with upscaling rather than checkerboarding."

.

X1X does seem to support CB at the hardware level with access to ID buffer. The extent of its support compared to PS4Pro might be different though.

 

[Globalisateur]

I will quote myself again from a few pages back:
.

X1X does seem to support CB at the hardware level with access to ID buffer. The extent of its support compared to PS4Pro might be different though.

IMO "GPU extensions" means accessing to lower software functions, "closer to the metal" part of the hardware, similar to those "shader extensions".

https://gpuopen.com/gcn-shader-extensions-for-direct3d-and-vulkan/

Also he is talking about "efficient" rendering, not free rendering. If there was some real dedicated hardware customizations they would have spelled it out.

 

[scently]

IMO "GPU extensions" means accessing to lower software functions, "closer to the metal" part of the hardware, similar to those "shader extensions".

https://gpuopen.com/gcn-shader-extensions-for-direct3d-and-vulkan/

Also he is talking about "efficient" rendering, not free rendering. If there was some real dedicated hardware customizations they would have spelled it out.

Whatever customization Sony might have done is also a gpu extension, I am not sure why you have a problem with that language. And implementing CB is definitely not free for anybody, Sony or not. And they said hardware techniques...Anyway I am not here to claim which is superior, just pointing out that X1X does have hardware support for CB rendering with access to ID buffer.

As for them not going into it much, well remember they are trying to paint the X1X as a superior native 4k machine to the PS4Pro so it really doesn't pay them much to go indepth into something that shows it will use "tricks" to get there.

 

[Tkumpathenurple]

Whatever customization Sony might have done is also a gpu extension, I am not sure why you have a problem with that language. And implementing CB is definitely not free for anybody, Sony or not. And they said hardware techniques...Anyway I am not here to claim which is superior, just pointing out that X1X does have hardware support for CB rendering with access to ID buffer.

As for them not going into it much, well remember they are trying to paint the X1X as a superior native 4k machine to the PS4Pro so it really doesn't pay them much to go indepth into something that shows it will use "tricks" to get there.

I think Globalisateur has an issue with you saying the X1X has hardware support for checkerboarding and ID buffer because the text you quoted states "We have hardware techniques for making checkerboarding very efficient," which is too vague of a statement for your conclusion to follow.

So I'm taking the opposite stance to you: the X1X is superior, but we don't know of its hardware support for checkerboarding and ID buffer.

Also, stop the "hey, I'm just doing [blah]" because you're not "just" pointing something out: you're also wilfully failing to see from someone else's perspective so that you can be right.