I am possibly misunderstanding the slide from the official Polaris presentation that did not make it clear that the 2xFP16 load store is even possible just says supports native int16/FP16, while Sony mention the full FP16x2 packed function-operations rather than AMD when they discussed-leaked info on their architectures.
+ Tonga, Fiji, Iceland
PS4 Pro at least according to that PS4 architect.
Having seen that Eurogamer article in really makes me wonder about that MIMD theory I had with the attached scalars. Issuing 2 instructions to the unit, which then has a 16xSIMD and one or more scalars attached. A scalar being like a SIMD with up to 16(multiple of 4) cycle cadence fed through the same pipeline. Copy the vector operands into temporary registers and you have a scalar pipelined 16 deep with no dependencies. A vector register acting like a scalar memory bank. That's about as optimal as you can get for high clockspeeds. It also avoids a lot of the variable SIMD width issues. Even if there are masked off lanes a scalar would have little difficulty skipping ahead in any configuration. Multiple bonded scalars and you simply increase the stride. Going with MIMD just so the scalar and vector ALUs can share the same registers/banks and avoid a lot of data shuffling and porting. Although it seems likely there will be more ports. 2xFP16 could then also schedule on the SIMD or scalar pair.
Do you mean the PS4 Pro's support for 2x FP16? The way double-rate FP16 is implemented in other GPUs doesn't introduce multiple instruction issue.
If they're going through the same pipeline, then that raises questions about high clock speeds. Having no dependences would not change how every other stage would be structured, and the clock period would be limited by everything else.
Actually, quite a few things are fine with FP16 (could be upwards of 50% of all lighting and pixelshader stuff, but I'm no expert for this, others here are). How much one can gain from it varies wildly, of course, and also depends on other bottlenecks. But being able to invest more arithmetic power in certain areas is significant, even when algorithms have to be modified to take advantage of it. Some cross platform stuff is already written with FP16 calculations as a consideration. So there is at least some experience with it.
This would be for PS4 Pro and possibly Vega. My theory had two instructions issued for a VALU+scalar, but with some flexibility to map them differently. VALU+VALU, VALU+Scalar, or Scalar+Scalar could be issued within the MIMD unit. Constrained by available ports, all of which are vectors. Different than other GPUs, but similar to having multiple vector ALUs scheduled. It wouldn't exactly be double rate FP16 however as you'd likely lose some throughput to the scalars.
The scalar would have it's own internal registers to support the higher clocks. For scalarization it would consume vector operands and run up to 16 cycles without needing any data fed to it.
For execution on the integrated scalar it would be irrelevant. You would be reading 16 lanes just as if the VALU were executing the code. To conserve registers a compaction scheme would be required. A task for which the scalars may be well suited. The scalar I had would just be serializing vectors by copying operands into temporary registers it could more appropriately access.
Any idea how easy would it be to take a true DX12 game rendering engine/post processing effects that has parts designed and optimised heavily around FP16 and then port it to the PC and also that of FP32?
What you describe is more or less what Nvidia proposed for Echelon.
According to the ISA manual, memory instructions of the same category are guaranteed to be committed in order. But since practically the results would be returned from the memory hierarchy out of order, I'd assume there is some kind of load/store buffer. So deferring update is possible.
Definitely similar concepts, both coming from the same DARPA project. My proposal was a more hybrid approach between parallel (SIMD) and temporal (scalar/2-wide SIMT) though. Not quite as versatile as Echelon, but more performant for parallel, non-diverged workloads. Keeps the design compatible with GCN, but with the added ability to schedule 2 VALUs. That would provide a lot of flexibility without being overly complex. If scheduling a single VALU per cycle there should still be a performance gain so long as the scalar can't complete the wave within the 4 cycle cadence. For a full wave the SIMD would be idle every 4th (16th clock) cycle of the cadence. Obviously a lot of ways to configure the CU, just a question of how robustly the scheduling hardware is designed.
Yeah sort of between Ronny Krashinsky's patent and some work at Nvidia and also with Berkely University and Yunsup Lee, and that of Jan Lucas who started with DART/temporal SIMD architecture and investigating Scalarization and Termporal SIMT but that has evolved quite a bit now to Spatiotemporal SIMT (not publicly available-distributed).
