FWIW I agree, hence my preface, but it was too much to resist throwing more fuel on the fire about terminology
Asynchronous is clearly too general to describe anything about the actual execution though. Asynchronous really just means... not synchronous. In some sense all graphics APIs are asynchronous (they definitely are for CPU/GPU, and they are in many areas for the GPU internally already), and definitely DX12's queues are asynchronous regardless of the underlying implementation.
Asynchronous does work better above the layer of the abstraction, and concurrent works better below. AMD's asynchronous compute marketing seems to mix above and below that dividing line.
For some commonly agreed upon margin of error, since that does have an instantaneous component that might be briefly untrue in the case of hardware that can context switch or preempt.I actually like "simultaneous" and "simultaneously". No one can really misinterpret that
A masterpiece. Your work is done here.
That's not true. At least not in general. I don't know if one of the consoles works this way though and maybe that's where your info comes from.
It is speculative (as you say) as it's written on the XBO SDK which is where I'm getting my info from. However after going through all the documentation I haven't seen much evidence that MS has done anything to really modify the hardware after all is said and done. I'm leaning towards doubting they changed this aspect too. The default allocation according to the SDK is 4CU unless you specify for more, there was no indication if you could allocate less. I'll double check the API though and see how it lines up against the dx12 one.
But for async compute, isn't the idea to reserve less hardware to complete the jobs? I get that compute jobs depending on size will span over as many CU units as needed, but if the idea (for async compute) is to insert compute jobs where there are stalls in compute jobs (sync points in the shader, waiting for loading of resources etc), then ideally wouldn't you want to reserve less hardware?
yeah depending on the program, bottlenecks can shift between the different parts of the GPU, I think one of the Fable Legend's benchmark articles went into that, Fiji seems to be bottlenecked similarly to Hawaii and its derivatives. Similar to how tessellation will bottleneck Fiji earlier than Maxwell 2.
Having more CUs to complete a job would go faster. Yes, this part isn't so much in debate. It's a question of how large that job is. The idea of async compute isn't go make compute go faster, but to increase the utilization of the compute units, so wherever there are gaps the idea is to fill those gaps with smaller compute jobs that aren't latency sensitive. At least this is my take on it. I assume most async compute jobs are being called from frame N, while the GPU is working on N-1.
Aye. Pitcairn is by default a 2x4 + 4x3 configuration, and Cape Verde was 1x4 + 2x3. Depending on the specific GCN SKU and the number of disabled CUs for chip salvaging, you'll see 2-4 CUs per CU array.
For what it's worth I'm not 100% sure on how he's even doing that. Fable Legends is locked down. The INI files appear to be hardcoded in the EXE and regenerated at runtime, which locks out any obvious means of changing the settings beyond the 3 built-in modes.
