So people were supposed to believe every rumor out of VGLeaks (MOST of which have proven true) except the one that implies the PS4 GPU might be compromised (or optimized) in some way?
"Buffing" it doesn't cause issues but increased costs, but "nerfing" it does. You're compromising a well-thought design.
Why on earth would AMD or Sony want to nerf the 4 CUs? I don't see a logical explanation for doing that.
Everything else out of VGleaks at least made sense in some way. Making these 4 CUs sub-par doesn't.
You don't even need to schedule this by yourself (and shouldn't do it). Just throw graphics and compute tasks at the array at the same time (these are handled by different queues in hardware) and the hardware will sort out the work distribution to the CUs on its own (and is quite flexible in that, GCN can simultaneously run different tasks on the same CU). One can help in prioritizing important tasks though (GCN supports giving priorities). Only if one has really good reasons one could think about interfering with the mechanisms the hardware provides, i.e. reserving a few CUs for a special task, as this decreases the flexibility and likely the overall performance.It's all good. The challenge is to understand how things fit together. Even if the hardware is flexible, sometimes it is obscured by software layers for assorted reasons. The key thing here is how does libGCM work ? Is it as flexible as Cyan mentioned ? If so, then the 18 unified CU setup is "perfect". There is no need to structure the CUs artificially.
Actually, if one could instruct the command processor to schedule just up to a maximum of let's say 36 Wavefronts per CU instead of 40 and reserve a few kB register file and local storage space, one can always squeeze a few additional wavefronts to a CU if the need arises (then likely given a high priority so it gets always scheduled if the operands are ready). Other than that the latency hiding capabilities of the CUs are slightly diminished, the throughput seen by the game wouldn't change at all. So one doesn't need to preempt long running wavefronts on a CU, if one can still schedule another one which then takes the fast lane because of its high priority.The ACEs will monitor for when CUs and other resources are no longer needed. Once a kernel completes, the ACE can evaluate what queued tasks can fit in the freed up pool and work through things based on priority and other factors like task age.
There's no elegant way to handle the possibility that the CUs are running long-lived kernels without preemption. This is why I speculated on the OS or runtime calling dibs on a certain number of wavefronts and local store ahead of time with some kind of placeholder shader or runtime trickery.
The game wouldn't really know unless it purposefully ran FP loops and saw the throughput numbers didn't match 18 CUs.
Actually, if one could instruct the command processor to schedule just up to a maximum of let's say 36 Wavefronts per CU instead of 40 and reserve a few kB register file and local storage space, one can always squeeze a few additional wavefronts to a CU if the need arises (then likely given a high priority so it gets always scheduled if the operands are ready). Other than that the latency hiding capabilities of the CUs are slightly diminished, the throughput seen by the game wouldn't change at all. So one doesn't need to preempt long running wavefronts on a CU, if one can still schedule another one which then takes the fast lane because of its high priority.
There's no elegant way to handle the possibility that the CUs are running long-lived kernels without preemption. This is why I speculated on the OS or runtime calling dibs on a certain number of wavefronts and local store ahead of time with some kind of placeholder shader or runtime trickery.
