[AMD_Robert] Concerning the AOTS image quality controversy

[William Gaatjes]

http://semiaccurate.com/forums/showthread.php?p=263871#post263871

I think you should read this post from Fottemberg, about FP16 on Pascal GPUs.

The post is from 29th may. Few days before the AMD presentation, and the benchmarks. We have to wait for effects of investigation by Oxide to conclude anything.

The posters there mention something interesting, the asynchronous shaders row of the table is removed from the new table on wikipedia :

http://semiaccurate.com/forums/showthread.php?t=8757&page=150

https://en.wikipedia.org/wiki/Feature_levels_in_Direct3D#Direct3D_12

Why would that have been done ?

 

[flopper]

The posters there mention something interesting, the asynchronous shaders row of the table is removed from the new table on wikipedia :

http://semiaccurate.com/forums/showthread.php?t=8757&page=150

https://en.wikipedia.org/wiki/Feature_levels_in_Direct3D#Direct3D_12

Why would that have been done ?

Guess why..is spelled n v i d i a d o n o t w a n t t h a t t o b e k n o w n.
wiki isnt btw any official site, anyone can edit stuff.

 

[William Gaatjes]

Guess why..is spelled n v i d i a d o n o t w a n t t h a t t o b e k n o w n.
wiki isnt btw any official site, anyone can edit stuff.

I read a similar response on the semiaccurate forum. :\
Weird that people go to such extents if that turns out to be true. Valuable time that can be used to game is now possibly used to manipulate people.

 

[Adul]

The posters there mention something interesting, the asynchronous shaders row of the table is removed from the new table on wikipedia :

http://semiaccurate.com/forums/showthread.php?t=8757&page=150

https://en.wikipedia.org/wiki/Feature_levels_in_Direct3D#Direct3D_12

Why would that have been done ?

Just look at the revision history. it has changed quiet a few times.

https://en.wikipedia.org/w/index.php?title=Feature_levels_in_Direct3D&action=history

 

[William Gaatjes]

Just look at the revision history. it has changed quiet a few times.

https://en.wikipedia.org/w/index.php?title=Feature_levels_in_Direct3D&action=history

Indeed. Lot of different opinions, when reading the comments about why it is changed back and forth.

 

[renderstate]

Async shaders are NOT a DX12 feature, only and AMD marketing term. You can't query DX12 to know whether it's supported or not. ALL DX12 HW must support multiple graphics and compute queues but there is no requirements on how tasks in these queues must be scheduled. That table is about DX12 features an app can query to determine support level.

Oh surprise, yet another non existent conspiracy originated by the usual fanboy that is so popular around here


Moreover Pascal *does support* concurrent execution of graphics and compute tasks. But you guys keep going on with this myth that it doesn't..

 

[3DVagabond]

Async shaders are NOT a DX12 feature, only and AMD marketing term. You can't query DX12 to know whether it's supported or not. ALL DX12 HW must support multiple graphics and compute queues but there is no requirements on how tasks in these queues must be scheduled. That table is about DX12 features an app can query to determine support level.

Oh surprise, yet another non existent conspiracy originated by the usual fanboy that is so popular around here


Moreover Pascal *does support* concurrent execution of graphics and compute tasks. But you guys keep going on with this myth that it doesn't..

Does it support DX12 Async compute?

 

[renderstate]

Does it support DX12 Async compute?

Have you actually read what I wrote? In DX12 *there is not a feature called async compute*. DX12 says HW must support separate command queues for graphics and compute, that's it. DX12 does not specify how tasks from these queues are scheduled.

What you really want to ask is "does HW X support CONCURRENT scheduling of compute and graphics tasks" but this is not a capability you can query in DX12 since the API doesn't even dictates how work is scheduled.

Of course, if a GPU can concurrently schedule compute and graphics tasks, it's an advantage since it might improve performance. There are also cases where it can impact performance (caches being thrashed due to the increased pressure from multiple tasks working on different data sets) but it's up to the developer playing with it and see how it behaves on different HW.

Also if a GPU sucks at filling its units with gfx work only (see Fury) you are likely to see better performance with async compute. If a GPU is already very good at filling its units with gfx tasks only then you are not going to see much improvement because there is very little to improve!

If a HW vendor proudly says they can get massive gains with async compute then it's saying "our chip kind of sucks at scheduling graphics work but you can partially fix that by scheduling compute work at the same time". There is nothing wrong with that, it's a good capability to have, but many don't really understand it!

NVIDIA already said at the Editor's day that Pascal can run gfx and compute tasks concurrently. They even demoed it. Why people are still spreading AMD FUD I don't know. Oh well.. I do know why..






Calling members or referring to them as "fanboys" is not allowed.


esquared
Anandtech Forum Director

 

[Keysplayr]

It's likely that your posts were read. Just not accepted.
I would suggest posting some sources for your claims, because no doubt they are scouring the net with 70 search engines to find sources that only specificly contradict everything you just said.
And to top it off, they are betting you are too lazy or feel its a waste of your time to do post your sources, and in their minds, they are correct by way of default or forfeit.
FYI.

 

[Abwx]

Async shaders are NOT a DX12 feature, only and AMD marketing term.

Straight from Microsoft site :

Direct3D 12 provides granular access to the 3D, compute and copy engines, using queues and command lists.

Asynchronous compute and graphics example

This next example allows graphics to render asynchronously from the compute queue. There is still a fixed amount of buffered data between the two stages, however now graphics work proceeds independently and uses the most up-to-date result of the compute stage as known on the CPU when the graphics work is queued. This would be useful if the graphics work was being updated by another source, for example user input. There must be multiple command lists to allow the ComputeGraphicsLatency frames of graphics work to be in flight at a time, and the function UpdateGraphicsCommandList represents updating the command list to include the most recent input data and read from the compute data from the appropriate buffer.

The compute queue must still wait for the graphics queue to finish with the pipe buffers, but a third fence (pGraphicsComputeFence) is introduced so that the progress of graphics reading compute work versus graphics progress in general can be tracked. This reflects the fact that now consecutive graphics frames could read from the same compute result or could skip a compute result. A more efficient but slightly more complicated design would use just the single graphics fence and store a mapping to the compute frames used by each graphics frame.

https://msdn.microsoft.com/en-us/library/windows/desktop/dn899217(v=vs.85).aspx

 

[caswow]

Source: Nvidia

 

[renderstate]

Please read what you quote. I'll do it for you:

"This next example *allows* graphics.."

The API does not mandate how work should be scheduled. The API mandates the HW must support multiple queues. That's all.

The text you quoted is about having multiple command queues that enable async compute, which is an implementation detail (an important one!) left to the hardware vendor. The API does not mandate it. BTW this was already repeated a million times before by others but I see there is no way for people to accept it and move on.

 

[renderstate]

It's likely that your posts were read. Just not accepted.
I would suggest posting some sources for your claims, because no doubt they are scouring the net with 70 search engines to find sources that only specificly contradict everything you just said.
And to top it off, they are betting you are too lazy or feel its a waste of your time to do post your sources, and in their minds, they are correct by way of default or forfeit.
FYI.

I was about to agree with you but then Abwx quotes something straight from MS website without reading it and understanding what it means. It's a lost battle, there is no real interest in learning anything. I see people going to great lengths to confirm their personal bias.

 

[ShintaiDK]

I was about to agree with you but then Abwx quotes something straight from MS website without reading it and understanding what it means. It's a lost battle, there is no real interest in learning anything. I see people going to great lengths to confirm their personal bias.

+1 :thumbsup:

 

[William Gaatjes]

Async shaders are NOT a DX12 feature, only and AMD marketing term. You can't query DX12 to know whether it's supported or not. ALL DX12 HW must support multiple graphics and compute queues but there is no requirements on how tasks in these queues must be scheduled. That table is about DX12 features an app can query to determine support level.

Oh surprise, yet another non existent conspiracy originated by the usual fanboy that is so popular around here


Moreover Pascal *does support* concurrent execution of graphics and compute tasks. But you guys keep going on with this myth that it doesn't..

Funny that i am a fanboy when all i do is ask why it is left out. That kind of gives away your attitude towards AMD and Nvidia.
I own diverse hardware from both companies and never got disappointed. But that is because i read up on what i am going to buy and compare it to my list of hardware wishes before i make a decision.

 

[maddie]

Am I understanding the table properly when it says this.

[Direct3D 12 optional feature support matrix by vendor/GPU series]

A red herring argument to claim that this about it not being a mandatory feature.

AFAIK none are saying this, just that it is a VERY beneficial feature to have utilized. To not have it is to be disadvantaged.

 

[renderstate]

Am I understanding the table properly when it says this.

[Direct3D 12 optional feature support matrix by vendor/GPU series]

A red herring argument to claim that this about it not being a mandatory feature.

AFAIK none are saying this, just that it is a VERY beneficial feature to have utilized. To not have it is to be disadvantaged.

Since you asked: you are not properly understanding the table. An optional feature is exactly that, something that can be optionally supported or not. Async compute is not a feature specified in DX12 specs, it's a feature enabled by DX12 specs (although I ca see how a clever HW + SW could support it transparently in DX11 too, since unlike in DX12 the driver knows the dependency graph)

Concurrently running graphics and compute in DX12 is not an optional feature. It's not a mandatory feature either. For the 1000th time: the API *does not mandate* concurrent scheduling of graphics and computer, optionally or not. Perhaps future versions of DX will (it would be nice!) but currently this is not the case, which is why async compute isn't in that table and it should not be in that table.

 

[Piroko]

Async shaders are NOT a DX12 feature, only and AMD marketing term. You can't query DX12 to know whether it's supported or not. ALL DX12 HW must support multiple graphics and compute queues but there is no requirements on how tasks in these queues must be scheduled. That table is about DX12 features an app can query to determine support level.

Correct, the reason it was removed is because it's a marketing term from AMD.

Oh surprise, yet another non existent conspiracy originated by the usual fanboy that is so popular around here

That's your own prejudice. Nvidia is being called out by their own fans just as much.

Moreover Pascal *does support* concurrent execution of graphics and compute tasks. But you guys keep going on with this myth that it doesn't..

To my understanding Pascal can now switch between Compute and Graphics at the GPC boundary, which definitely is a form of concurrent compute + graphics. I'm just not entirely convinced of the usefulness when you can only switch between the two in 25% granularity (GP106 might be limited to 33% or 50% granularity, GP102 could increase this to 17%).
In comparison, AMD can switch between the two workloads in >3% granularity on Hawaii to stuff holes in the graphics pipeline. This seems a lot more useful to be honest to fill both expected and unexpected gaps in the graphics workload.

 

[gamervivek]

Source: Nvidia

nvidia PR have learned nothing from the 3.5GB fiasco it seems. :sneaky:

 

[maddie]

Since you asked: you are not properly understanding the table. An optional feature is exactly that, something that can be optionally supported or not. Async compute is not a feature specified in DX12 specs, it's a feature enabled by DX12 specs (although I ca see how a clever HW + SW could support it transparently in DX11 too, since unlike in DX12 the driver knows the dependency graph)

Concurrently running graphics and compute in DX12 is not an optional feature. It's not a mandatory feature either. For the 1000th time: the API *does not mandate* concurrent scheduling of graphics and computer, optionally or not. Perhaps future versions of DX will (it would be nice!) but currently this is not the case, which is why async compute isn't in that table and it should not be in that table.

Did you understand what I wrote? Let me repeat it.

A red herring argument to claim that this about it not being a mandatory feature.

AFAIK none are saying this, just that it is a VERY beneficial feature to have utilized. To not have it is to be disadvantaged.

Who is saying that async-compute is mandatory? NO ONE.
Async-compute is a feature that AMD has developed and it provides a large performance increase. So what if it's not required for DX12, having it means you can get increased performance and that is what some are saying.

Incidentally here is an article containing an exchange among developers enthusing about async-compute and encouraging each other to use it. They must be crazy.

http://wccftech.com/async-compute-p...tting-performance-target-in-doom-on-consoles/

 

[Erenhardt]

Some are still in full denial even after nv admitted otherwise.

It is not the first time we see a degradation in visuals on nv hardware. And I guess not the last one either.

 

[Glo.]

@renderstate. DirectX12 is Mantle + Direct3D 12.

Asynchronous Compute is feature in Direct3D 12.

Asynchronous Shaders are emanation of this feature. The are executed in the application, to render the scheduled tasks.

All of this comes from Asynchronous Compute. Asynchronous Shaders is this: Shaders executed Asynchronously.

All of what you write is technically correct. The problem is that you are missing the point in your information that are very important for whole picture to be seen.

Shaders can be executed asynchronously on every hardware. The problem is this: how will this action affect the performance. Will it improve it or will it make it tank? That is the point of Asynchronous Compute(not shaders).

 

[sirmo]

Source: Nvidia

I about spilled my coffee when I saw that, haha, whoever put those slides together is clueless.

 

[Keysplayr]

No point talking if nobody can understand each other. Which every post seems to imply.

 

[Kenmitch]

No point talking if nobody can understand each other. Which every post seems to imply.

Yep.

What's your take on the lack of visual quality shown in the side by side comparison?