Most were answered by their silence. more ALUs on the GPU is a no, otherwise the FLOPs rating would be higher. GPU on the system chip with the ARM is also a no, otherwise it'd have been mentioned (at least nothing substantial, though there may be some display hardware of sorts, maybe, though I seriously doubt it). There's nothing outstanding that needs to be known to understand the system and Sony's objectives.
Yeah, doesn't seem likely; how would you get the image out of the south bridge anyway, with display interface hardware very likely integrated into the APU? ...You'd have to wake that up too just to display anything, so why even bother with putting graphics anywhere else?
So, 8 years after the release of the 360, and 7 years after the PS3. Can you tell me how much memory is reserved for the PS3 or 360? Not second or third hand reports from a dev, but a statement by the console maker to the public, or even a gaming site. What clock speed does the XMA Decoder on the 360 run at? Not even developers know this.
Don't ask me. I'm just pointing out that 7 years into a console lifecycle, there are still unknown things (to end-users, and developers in some cases) about both current consoles. The memory reservation numbers are covered by NDA, so the numbers you've seen are hearsay, rumors or extrapolations from the few public docs out there. I'm afraid if you believe Sony is ever going to announce the specs of the ARM chip, or detailed specs on their audio processor, or how much the memory reservations are, you're probably going to be disappointed. Some of that we'll glean from leaked docs and hearsay (like memory reservations), and some of it we'll never fully know (Like the clock speed for the XMA decoder). I'd be inclined to put the ARM chip in the latter category.
There are often times when ALUs are idle. Sometimes it's while rendering shadow maps which often don't have heavy vertex shaders and have no pixel shaders. Other times you might be limited by blending for translucency, etc. rather than shaders. If you have ALU heavy compute work it could be very efficient to run it in parallel with certain graphics workloads.
The distinction between compute and graphics is graphics feeds the rasterizer while compute feeds a data structure in memory. Until the rasterizer is accessible from the shader core there will continue to be a distinction at the hardware level. The distinction from a software viewpoint will likely remain until there is no API.
My question to you is this...
Why doesn't that consumer all the ALUs for a very short time then? I'd have thought, in my naivety, that vertex work saturates the ALUs for a brief moment to churn through those jobs, and then the ALUs sit on the pixel work for much of the scene churning through that work, both pixels and then post processing. In my understanding of US GPUs, there's not going to be a moment when a few ALU pipes are active and the rest are idle, or when the whole set of ALUs are idle waiting for something to do.
