Mahigan escribió:*This is a work in progress and should be viewed as such*It's been several weeks since the Ashes of the Singularity benchmarks hit the PC Gaming scene and brought a new feature into our collective vocabulary. Throughout these past few weeks, there has been a lot of confusion and mis-information spreading throughout the web as a result of the rather complex nature of this topic. In an effort, to combat this misinformation,
@GorillaSceptre asked if a new thread could be started in order to condense a lot of the information which has been gathered on the topic. This thread is my no means final. This thread is set to change as new information comes to light. If you have new information, feel free to bring it to the attention of the Overclock.net community as a whole by way of commenting on this thread.
As things stand right now, Sept 6, 2015, we're waiting for a new driver, from nVIDIA, to rectify an issue which has inhibited the Maxwell 2 series from supporting Asynchronous Compute. Both Oxide, the developer of the Ashes of the Singularity video game and benchmark, and nVIDIA are working hard to implement a fix to this issue. While we wait for this fix, lets take an opportunity to break down some misconceptions.
nVIDIA HyperQnVIDIA implement Asynchronous Compute through what nVIDIA calls "HyperQ". HyperQ is a hybrid solution which is part software scheduling and part hardware scheduling. While little information is available as it pertains to its implementation in nVIDIAs Maxwell/Maxwell 2 architecture, we've been able to piece together just how it works from various sources.
Now I'm certain many of you have seen this image floating around, as it pertains to Kepler's HyperQ implementation:
Warning: Spoiler! (Click to show)
Created with GIMP
What the image shows is a series of CPU Cores (indicated by blue squares) scheduling a series of tasks to another series of queues (indicated in black squares) which are then distributed to the various SMMs throughout the Maxwell 2 architecture. While this image is useful, it doesn't truly tell us what is going on. In order to figure out just what those black squares represent, we need to take a look at the nVIDIA Kepler White Papers. Within these white papers we find the HyperQ being defined as such:
Warning: Spoiler! (Click to show)
Based on this diagram we can infer that HyperQ works through two software components before tasks are scheduled to the hardware:
Grid Management Unit
Work Distributor
So far the scheduling works like this:
The developer sends the batch to the nVIDIA software driver
Within the nVIDIA software driver, the batch is held in a Grid Management Unit
The Grid Management Unit transfers 32 pending grids (32 Compute or 1 Graphic and 31 Compute) to the Work Distributor
The Work Distributor transfers the 32 Compute or 1 Graphic and 31 Compute tasks to the SMMs which are a hardware component withing the nVIDIA GPU.
The components within the SMMs which receive the tasks are called Asynchronous Warp Schedulers and they assign the tasks to available CUDA cores for processing.
Quote:
That's all fine and dandy but what about the extra CPU Overhead associated with scheduling in software?While it is true that nVIDIAs HyperQ solution would incur a larger degree of CPU overhead, under DirectX12, than AMDs hardware scheduling implementation, it remains to be seen whether or not this will affect performance. It could very well affect performance on, say, a Core i3 or AMD FX processor but you don't see too many people pairing a powerful nVIDIA GeForce GTX 970/980/980 Ti with an under-powered CPU. If folks have the money to dish out on a powerful GPU, they tend to also have the money to dish out on a robust Quad Core processor (Core i5/i7 series).
Therefore there seems to be confusion as to what the "software scheduling'" means. It doesn't mean that Maxwell 2 will be doing compute tasks over the CPU. It means that there is a limitation added to the way nVIDIAs solution can execute tasks in parallel. It's all about what David Kanter was saying on preemption here (starts around 1:18:00 into the video):
Warning: Spoiler! (Click to show)
The main problem with nVIDIAs HyperQ implementation is in terms of preemption. It is in part due to the software scheduling aspect of nVIDIAs Maxwell 2 solution as well as the limitations, in terms of Not being able to execute a second compute task until the end of a draw call boundary (lag or latency being introduced) and lack of error verification, from the Asynchronous Warp Schedulers.
Example:
Say you have a graphic shader, in a frame, that is taking a particularly long time to complete, with Maxwell2, you have to wait for this graphic shader to complete before you can execute another task. If a graphic shader takes 16ms, you have to wait till it completes before executing another graphic or compute command. This is what is called "slow context switching". Every millisecond, brings down your FPS for that frame. Therefore if a graphic shader takes 16ms to execute, a compute task takes 20ms to execute and you've got a copy command taking 5 ms to execute, you end up with a frame which takes 41ms to execute. This introduces a delay, or lag/latency, between executions. While preemption wasn't important for DX11, and nVIDIA primarily designed their Kepler/Maxwell/Maxwell 2 architectures with DX11 in mind, it becomes quite important for DX12 Asynchronous Compute as well as VR.
Warning: Spoiler! (Click to show)
Quote:
Why is this different than GCN?With GCN, you can execute tasks simultaneously (without a waiting period), the ACEs will also check for errors and re-issue, if needed, to correct an error. You don't need to wait for one task to complete before you work on the next. So say, on GCN, a Graphic shader task takes 16ms to execute, in that same 16ms you can execute many other tasks in parallel (like the compute and copy command above). Therefore your frame ends up taking only 16ms because you're executing several tasks in parallel. There's little to no latency or lag between executions because they execute like Hyper-threading (hence the benefits to the LiquidVR implementation).
Warning: Spoiler! (Click to show)
Quote:
What does this mean for gaming performance?Developers need to be careful about how they program for Maxwell 2, if they aren't... then far too much latency will be added to a frame. This is true even once nVIDIA fix their driver issue. It's an architectural issue, not a software issue.
Quote:
It's architectural? How so?Well that's all in how a context switch is performed in hardware. In order to understand this, we need to understand something about the Compute Units found in every GCN based Graphics card since Tahiti. We already know that a Compute Unit can hold several threads, executing in flight, at the same time. The maximum amount of simultaneous threads executed concurrently, per CU, is 2,560 (40 Wavefronts @ 64 Threads ea). GCN can, within one cycle, switch to and begin the execution of a different Wavefront . This allows the entire GCN GPU to perform both a Graphics and Compute task, simultaneously, with extremely low-latency being associated with switching between them. Idle CUs can be switched to a different task at a very fine grained level with a minimum performance penalty associated with the switch.
Warning: Spoiler! (Click to show)
Quote:
Well that's GCN's architecture... What about Maxwell 2 and that Slow Context Switching thing?
In terms of a Context Switch, Maxwell 2 can switch between a Compute and Graphics task in a coarse-grained fashion and pays a penalty (sometimes to the order of over a thousand cycles in worst case scenarios) for doing so. While Maxwell 2 excels at ordering tasks, based on priority, in a way which minimizes conflicts between Graphics and Compute tasks; Maxwell 2 doesn't necessarily gain a boost in performance from doing so. The reason for this is that Maxwell 2 takes a rather large hit when switching contexts. This is why it remains to be seen if Maxwell 2 will gain a performance boost from Asynchronous Compute. A developer would need to finely tune his/her code in order to derive any sort of performance benefits. From all the sources I've seen, Pascal will perhaps fix this problem (but wait and see as it could just be speculation). There is also evidence that Pascal will not fix this issue as you can see here (provided by
@Vesku):
Warning: Spoiler! (Click to show)
Source here
nVIDIA may not have thought that the industry would jump on DX12 the way it is right now... pretty much every single title, in 2016, will be built around the DX12 API. We'll even get a few titles in a few months in 2015. What's worse is that the majority of titles, in 2015 and 2016, have partnered with AMD. We can therefore be quite certain that Asynchronous Compute will be implemented, for AMD GCN at least, throughout the majority of DX12 titles to arrive in 2015/2016.
Warning: Spoiler! (Click to show)
There is no underestimating nVIDIAs capacity to fix their driver. It will be fixed. As for the performance derived out of nVIDIAs HyperQ solution? Best to wait and see.
? ![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[fiu]](/images/smilies/fiu.gif "disimulando")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
