• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Pascal async compute

M

MangoSeed

[H]ard|Gawd
Joined
Oct 15, 2014
Messages
1,447
From the official press release.

A Quantum Leap in Gaming: NVIDIA Introduces GeForce GTX 1080

"Increases in bandwidth and power efficiency allow the GTX 1080 to run at clock speeds never before possible -- over 1700 MHz -- while consuming only 180 watts of power. New asynchronous compute advances improve efficiency and gaming performance. And new GPU Boost™ 3 technology supports advanced overclocking functionality."

Reviews should be interesting.
 
MangoSeed said:
From the official press release.

A Quantum Leap in Gaming: NVIDIA Introduces GeForce GTX 1080

"Increases in bandwidth and power efficiency allow the GTX 1080 to run at clock speeds never before possible -- over 1700 MHz -- while consuming only 180 watts of power. New asynchronous compute advances improve efficiency and gaming performance. And new GPU Boost™ 3 technology supports advanced overclocking functionality."

Reviews should be interesting.
Click to expand...


Note the careful phrasing. If I had to guess, they still don't have hardware for it, but managed to "improve" software async emulation on the new hardware.
 
razor1 said:
Operative words, "if I had to guess"
Click to expand...

Of course. I don't know for sure. But I am quite familiar with PR speak. If they had it baked into pascal hardware, they'd be crystal clear about it. And let's not forget that NVidia also claimed it could do async on Maxwell, before then denying they ever said it and adopting a "who needs async anyway" attitude.

Don't be SUCH an Nvidia homer that you can't see through the PR gobbledygook.
 
They didn't talk about any DX12 feature sets, there are features in Pascal, that are way outside of DX12 spec and will come into play in Vulkan through vender specific extensions which weren't talked about either.

Why, cause right now its not important. When they are they will talk about them.
 
Zion Halcyon said:
Note the careful phrasing. If I had to guess, they still don't have hardware for it, but managed to "improve" software async emulation on the new hardware.
Click to expand...

They probably wouldn't promote it either way. Due to AMD marketing and press hype, async is closely associated with AMD. Notice that one of the killer apps for async is VR timewarp yet no mention of that either.
 
  • Like
Reactions: N4CR
like this
async timewarp, is not the same thing as async shaders. Async timewarp uses preemption and context switching to push certain things to do be done first.
 
razor1 said:
async timewarp, is not the same thing as async shaders. Async timewarp uses preemption and context switching to push certain things to do be done first.
Click to expand...

Not on AMD cards. Their timewarp implementation is based on a high priority async compute queue, not pre-emption.
 
that is a separate compute queue which is still not the same thing as async shaders.
 
razor1 said:
that is a separate compute queue which is still not the same thing as async shaders.
Click to expand...

Async shaders is just GCN's ability to run a compute kernel concurrently with other work. No need to over complicate it.
 
all this time developing Pascal and knowing how AMD is harping on their Async performance and Nvidia still cannot get it working for their next-gen cards?...why is it so difficult?...some kind of hardware limitation?...special sauce that only AMD engineers have access to?
 
MangoSeed said:
Async shaders is just GCN's ability to run a compute kernel concurrently with other work. No need to over complicate it.
Click to expand...


No its not they have to be in the same queue (graphics), two kernels being executed in the same queue.

By saying what you are saying you are over complicating things and confusing what is what.
 
razor1 said:
No its not they have to be in the same queue (graphics), two kernels being executed in the same queue.

By saying what you are saying you are over complicating things and confusing what is what.
Click to expand...

AMD can absolutely schedule and execute work concurrently from the graphics and compute queues.

If you disagree with Microsoft and AMD you should take it up with them. Otherwise I have no idea what point you're trying to make.
 
  • Like
Reactions: Yakk
like this
rinaldo00 said:
Just like every post you made here
Nvidia GeForce GTX 1080 rumor mill just blew up.
Click to expand...


Its no longer a rumor and I wasn't rumor mongering in my posts either.

Aysnc shaders: there is no such thing, AMD made it as a marketing term for their hardware

Async compute: DirectX 12, Vulkan, Cuda, Ogl, all support it and is supported by all graphics cards

Multi engine: Dx12, Vulkan, supported by all graphics cards DX12 and up complaint.

How hard is this to understand?

Three different things completely.

Now lets add in Async time warp:

A completely different thing more associated with multi engine. Having multi compute queues going at the same time, but prioritizing one or more of the compute queues to start and finish separately from the other queues.

the async part of async timewarp, is asynchronicity of a complete queue, not of the individual instructions.
 
polonyc2 said:
all this time developing Pascal and knowing how AMD is harping on their Async performance and Nvidia still cannot get it working for their next-gen cards?...why is it so difficult?...some kind of hardware limitation?...special sauce that only AMD engineers have access to?
Click to expand...

Pascal development took at least 2 years do develop for according to Nvidia. Can't bake things into it at the last second.
 
async shaders is when you have a graphics queue going and you interject compute instructions into the graphics queue (both kernels are executed in the same queue) Only AMD hardware is capable of this (with holding pascal in the conversation here as we don't know about it yet).
 
razor1 said:
async shaders is when you have a graphics queue going and you interject compute instructions into the graphics queue (both kernels are executed in the same queue) Only AMD hardware is capable of this (with holding pascal in the conversation here as we don't know about it yet).
Click to expand...

Can you share a source? Because that definitely does not jive with either Microsoft's or AMD's papers on the subject.

Straight from AMD:

"A basic requirement for asynchronous shading is the ability of the GPU to schedule work from multiple queues of different types across the available processing resources."

http://amd-dev.wpengine.netdna-cdn....10/Asynchronous-Shaders-White-Paper-FINAL.pdf
 
razor1 said:
Its no longer a rumor and I wasn't rumor mongering in my posts either.

Aysnc shaders: there is no such thing, AMD made it as a marketing term for their hardware

Async compute: DirectX 12, Vulkan, Cuda, Ogl, all support it and is supported by all graphics cards

Multi engine: Dx12, Vulkan, supported by all graphics cards DX12 and up complaint.

How hard is this to understand?

Three different things completely.

Now lets add in Async time warp:

A completely different thing more associated with multi engine. Having multi compute queues going at the same time, but prioritizing one or more of the compute queues to start and finish separately from the other queues.

the async part of async timewarp, is asynchronicity of a complete queue, not of the individual instructions.
Click to expand...
Amd fanbois are gnashing their teeth and whining because Nvidia is officially releasing new cards which put even more distance between Amd who are losing hundreds of millions every year. AMD has already admitted they can't match Pascal so it's a horrible day for them.
 
polonyc2 said:
all this time developing Pascal and knowing how AMD is harping on their Async performance and Nvidia still cannot get it working for their next-gen cards?...why is it so difficult?...some kind of hardware limitation?...special sauce that only AMD engineers have access to?
Click to expand...
You dont know that yet, if you can hold out a few days for reviews you can make educated comments.
 
MangoSeed said:
Synchronizing resource state does not preclude concurrent execution.

Btw, on that same link you posted from Microsoft there's an example of async execution from multiple queues. Read the entire thing ;)
Click to expand...


Be specific of what type of async execution.

This is the confusion.

if you start putting compute instructions into the graphics queue, guess what you have to share resources and sync resources between the two queues, by doing so some ALU's in the same SM have to do compute instructions (kernel execution) and some have to do graphics instructions (kernel executions).

That is where things get messed up and this is a feature of AMD hardware, and nV doesn't have this feature (with standing pascal) nor does Intel, and its not part of the DX spec.

The example you stataed on MS's site, is for Async compute another words having two separate queues asynchronously from each other this has nothing to do with AMD's async shaders.
 
Wait, so reading through the PR fluff... the 1080 does not have a hardware asynchronous scheduler? Everything still has to be planned and coded pre-emptively?
 
it does have it, they didn't talk about it to the general public, its in the deep dive which journalist were privy too the day after the public showing.

The problem was each SM of maxwell 2 can do either a compute queue or a graphics queue, now having multiple SM's you can do both at the same time so it fulfills Dx's requirement of multi engine (and also async compute) But doing async shaders AMD's way it caused a problem because now the program is asking the driver to split both types of work over one SM, which the driver looks at it and approximates what it should do at what time. Once the SM goes from lets say a compute to graphics, or vice versa, the driver might approximate incorrectly and there isn't enough work for the second queue to full utilize the SM, you have under utilization going on, and this is why we see the performance drops.

The async scheduler is not important, the scheduler in Maxwell 2 and prior can already do this type of scheduling, each individual SM in Maxwell 2 and prior, can't do compute and graphics at the same time. This is where things got confusing, because async compute is not this lol, async shaders requires this, so trying to force async shaders to work on Maxwell 2 and prior is just a bad idea because there will be times where things just fall apart due to under utilization. You will get better utilization by letting the driver pick and choose what to do and when.
 
Last edited:
Nenu said:
You dont know that yet, if you can hold out a few days for reviews you can make educated comments.
Click to expand...

if Nvidia really had amazing async performance with their Pascal cards don't you think they would be crowing about it and hyping it to the moon by this point??...use your brain...AMD has been holding this over Nvidia's head ever since DX12 benchmarks and games started to be released...it's the only thing really that AMD can brag about...and to think that Nvidia wouldn't leak out Pascal async results if it really performed better then AMD is insane...their engineers and driver team will probably be working on it till the last minute...
 
polonyc2 said:
if Nvidia really had amazing async performance with their Pascal cards don't you think they would be crowing about it and hyping it to the moon by this point??...use your brain...AMD has been holding this over Nvidia's head ever since DX12 benchmarks and games started to be released...it's the only thing really that AMD can brag about...and to think that Nvidia wouldn't leak out Pascal async results if it really performed better then AMD is insane...their engineers and driver team will probably be working on it till the last minute...
Click to expand...

Its in Pascal, they have already mentioned it in their blog and the deep dive went into much more, and since it has already been stated by a person who was in the deep dive for pascal gaming cards who is also a programmer, I would take his word for it.

Async results won't be better than AMD cards cause utilization of nV's ALU's are higher (current generation of cards)so the % gain for async shaders will automatically be less since theoretical limits can't be broken.

The main thing is at least you won't see negative results if the shaders are done right and also the code paths can be closer now hopefully........

Async is not a performance booster in the sense it increases performance, it is to regain performance from under utilized ALU's so there is a hard limit to what that gain can be and it changes on a per GPU, per IHV level.
 
Last edited:
polonyc2 said:
if Nvidia really had amazing async performance with their Pascal cards don't you think they would be crowing about it and hyping it to the moon by this point??...use your brain...AMD has been holding this over Nvidia's head ever since DX12 benchmarks and games started to be released...it's the only thing really that AMD can brag about...and to think that Nvidia wouldn't leak out Pascal async results if it really performed better then AMD is insane...their engineers and driver team will probably be working on it till the last minute...
Click to expand...

You posted speculation as fact lol.
Up to you if you want to be known for your BS.
 
razor1 said:
The example you stataed on MS's site, is for Async compute another words having two separate queues asynchronously from each other this has nothing to do with AMD's async shaders.
Click to expand...

Let's agree to disagree.

DX12 defines multiple command queues. AMD can interleave work from multiple queues and can do this dynamically.

It appears Maxwell can do something similar but has to statically assign each SM to either graphics or compute so performance is hit or miss.

It's like back in the day when we had dedicated vertex and pixel shaders - performance would tank if you picked the wrong ratio and left too much hardware idle.

AMD's implementation has nothing to do with inserting compute commands into a graphics queue. I have no idea where you got that from and why you keep repeating it.
 
  • Like
Reactions: Yakk
like this
lets not lol nothing personal but its a clear definitions of what async compute is and I would like to clarify the confusion and I'm sure you are capable of understanding these concepts as you have easily demonstrated the ability to discuss about it.

If you want another one to explain it to you here:

AMD: Polaris / Arctic Islands (R* 4** series) Speculation, Rumors, and Discussion

sebbbi said:
It seems that people are still confusing terms "async compute", "async shaders" and "compute queue". Marketing and press doesn't seem to understand the terms properly and spread the confusion :)

Hardware:
AMD: Each compute unit (CUs) on GCN can run multiple shaders concurrently. Each CU can run both compute (CS) and graphics (PS/VS/GS/HS/DS) tasks concurrently. The 64 KB LDS (local data store) inside a CU is dynamically split between currently running shaders. Graphics shaders also use it for intermediate storage. AMD calls this feature "Async shaders".

Intel / Nvidia: These GPUs do not support running graphics + compute concurrently on a single compute unit. One possible reason is the LDS / cache configuration (GPU on chip memory is configured differently when running graphics - CUDA even allows direct control for it). There most likely are other reasons as well. According to Intel documentation it seems that they are running the whole GPU either in compute mode or graphics mode. Nvidia is not as clear about this. Maxwell likely can run compute and graphics simultaneously, but not both in the same "shader multiprocessor" (SM).

Async compute = running shaders in the compute queue. Compute queue is like another "CPU thread". It doesn't have any ties to the main queue. You can use fences to synchronize between queues, but this is a very heavy operation and likely causes stalls. You don't want to do more than a few fences (preferably one) per frame. Just like "CPU threads", compute queue doesn't guarantee any concurrent execution. Driver can time slice queues (just like OS does for CPU threads when you have more threads than the CPU core count). This can still be beneficial if you have big stalls (GPU waiting for CPU for instance). AMDs hardware works a bit like hyperthreading. It can feed multiple queues concurrently to all the compute units. If a compute units has stalls (even small stalls can be exploited), the CU will immediately switches to another shader (also graphics<->compute). This results in higher GPU utilization.

You don't need to use the compute queue in order to execute multiple shaders concurrently. DirectX 12 and Vulkan are by default running all commands concurrently, even from a single queue (at the level of concurrency supported by the hardware). The developer needs to manually insert barriers in the queue to represent synchronization points for each resource (to prevent read<->write hazards). All modern GPUs are able to execute multiple shaders concurrently. However on Intel and Nvidia, the GPU is running either graphics or compute at a time (but can run multiple compute shaders or multiple graphics shaders concurrently). So in order to maximize the performance, you'd want submit large batches of either graphics or compute to the queue at once (not alternating between both rapidly). You get a GPU stall ("wait until idle") on each graphics<->compute switch (unless you are AMD of course).
Click to expand...



No it is not like back in the day like like vertex or pixel shader, compute and graphics queues are nothing like that at all. Load balancing isn't done by the program, (which is what game dev's had to do with manually). This is done by the driver and handed off to the scheduler to finish up the tasks. The scheduler is already there for instructions, there is no way it can't be there, if it wasn't the GPU wouldn't be able to do any queues lol.
 
razor1 said:
"Aysnc shaders: there is no such thing, AMD made it as a marketing term for their hardware"
Click to expand...

Then you said;

"This is where things got confusing, because async compute is not this lol, async shaders requires this, so trying to force async shaders to work on Maxwell 2 and prior is just a bad idea because there will be times where things just fall apart due to under utilization. "
Click to expand...

Which one is it dude? Make up your mind.
 
razor1 said:
lets not lol nothing personal but its a clear definitions of what async compute is and I would like to clarify the confusion and I'm sure you are capable of understanding these concepts as you have easily demonstrated the ability to discuss about it.

If you want another one to explain it to you here:

AMD: Polaris / Arctic Islands (R* 4** series) Speculation, Rumors, and Discussion
Click to expand...

Thanks, I'm aware of sebbbi's comments on the topic.

The pixel/vertex shader analogy was to highlight the static (and less than optimal) approach nVidia is using. I assumed you would be able to follow that.

What specific point are you trying to make by constantly repeating that async shaders and async compute are not the same? AMD can run graphics alongside compute whether those tasks come from the same or multiple queues so why does it matter?
 
MangoSeed said:
Thanks, I'm aware of sebbbi's comments on the topic.

The pixel/vertex shader analogy was to highlight the static (and less than optimal) approach nVidia is using. I assumed you would be able to follow that.

What specific point are you trying to make by constantly repeating that async shaders and async compute are not the same? AMD can run graphics alongside compute whether those tasks come from the same or multiple queues so why does it matter?
Click to expand...

It's not less then optimal, what is optimal for one architecture is not optimal for another.

Async shaders its not just running along side that is multi engine all graphics cards dx12 complaint can do that. They have to have multiple queues to do that. The best way to say it is async shaders is an additional feature on top of multi engine which when used properly can give you better utilization of your cores.

N4CR said:
Then you said;



Which one is it dude? Make up your mind.
Click to expand...

They are three different things. async shaders is not async compute. The ability to do mutli enigne as well is not async shaders.
 
Good grief, another Async compute thread :(. Unless there are clear examples that are actually getting used in a program or game that shows any advantages - it is not worth the discussion. For a gamer I would only be interested in todays games that I can play now. Predicting future games and performance has proven futile.
 
razor1 said:
They are three different things. async shaders is not async compute. The ability to do mutli enigne as well is not async shaders.
Click to expand...

Sure, but why did you write this then:
razor1 said:
Aysnc shaders: there is no such thing, AMD made it as a marketing term for their hardware
Click to expand...


Then you said :
razor1 said:
"This is where things got confusing, because async compute is not this lol, async shaders requires this, so trying to force async shaders to work on Maxwell 2 and prior is just a bad idea because there will be times where things just fall apart due to under utilization. "
Click to expand...

So is Asynch shaders = bullshit AMD marketing and no such thing? Why then do you use that term to explain things later on?

I often find your posts informative just this is a pretty weird discrepancy, for you to change your mind in one thread. You come across a little as a Nvidia PR type after seeing this, you hardly ever say anything positive about AMD. Not that there is much positive at the moment but jiesh.. some praise would be nice to even things out when it is due!
 
N4CR said:
Sure, but why did you write this then:



Then you said :


So is Asynch shaders = bullshit AMD marketing and no such thing? Why then do you use that term to explain things later on?

I often find your posts informative just this is a pretty weird discrepancy, for you to change your mind in one thread. You come across a little as a Nvidia PR type after seeing this, you hardly ever say anything positive about AMD. Not that there is much positive at the moment but jiesh.. some praise would be nice to even things out when it is due!
Click to expand...


Asynchronous Compute versus Asynchronous Shaders: different terminology for the same thing.

In Short, Asynchronous Compute is a DX12-level feature opened up by the low-level access the API allows. Asynchronous Shaders are AMD's method for implementing said API instruction. The two terms SHOULD be used interchangeably, as AMD is not trying to patent the term. If someone tries to pull you up on saying one is not the other, they're being pedantic.
 
MangoSeed said:
Let's agree to disagree.

DX12 defines multiple command queues. AMD can interleave work from multiple queues and can do this dynamically.

It appears Maxwell can do something similar but has to statically assign each SM to either graphics or compute so performance is hit or miss.

It's like back in the day when we had dedicated vertex and pixel shaders - performance would tank if you picked the wrong ratio and left too much hardware idle.

AMD's implementation has nothing to do with inserting compute commands into a graphics queue. I have no idea where you got that from and why you keep repeating it.
Click to expand...

Due to that Maxwell SM limitation (best not to expand too much on this because a lot of posts were wiped on the subject including my questions and Sebbi's thoughts), will this mean developers will need to code multiple paths in a game for DX12 to support the difference between Kepler-Maxwell and Pascal...
I think it does.
Cheers
 
You must log in or register to reply here.
Back
Top