Hard Ball
Senior member
No, that's not what I was talking about, it's not about applications or benchmarks, but the limits placed on the computational throughput by the microarchitecture of the "SM" as NV calls it (it would be much more transparent to call it an SPMD cluster), the programming model used for this and other NV designs since G80, and the interaction of the two. Essentially, it's referring to the limits on the microarchitecture itself in terms of what the highest computational throughput would be possible in the case of an ideal instruction stream through the SPMD cluster.
Clearly I have not said enough to help you to understand what's going on. And maybe this needs to be done over multiple posts, if we need to get some more fundamental stuff right about microarchitectures.
The "dual issue" that you refered to, I see where you are getting that from; which is not exactly what I thought originally, but closely related. The "dual issue" that NV referred to in their PR blabs, which I just read (I work in computer architecture, so I usually only read technical documents, not public presentations or press releases), is not really ISSUE at all, it refers to the way that and SPMD program can be scheduled on the cluster.
An SPMD cluster (which in NV's vocab is SM) on G80 as well as G200 issues instructions in groups of threads that are tied to the same SPMD instruction stream, which NV calls a warp; usually minimum 6 such streams of 32 threads each are scheduled on a single SM through fine-grained multithreading (thread/stream switch on cycle). The local instr store (not exactly I-cache, since it can be explicitly manipulated by global scheduler of the overall compute core), contains these SPMD streams; the 32 threads in a single stream is directed down a single control path (no predication in the way that larrabee does branches), which means that they execute the same instruction i in the stream in lockstep in the perspective of the program, even if they are on temporally differnt cycles in hardware. The cluster's shedulers runs at the full core clock (what NV calls shader domain, but the non-shader domain is largely the non-programmable portion of the GPU), as does each of the execution units in the 8 regular pipelines as well as the SFUs in the cluster.
However, the issue ports from the scheduler in the cluster, let's call them 0 and 1, cannot be issued to on the same cycle, but need to be scheduled on alternate cycles. This is probably done for simplifying the way the programming model interacts with the hardware; in principle for the same reason as the way Intel larrabee's ring bus that can schedule data between a particular pair of node only on alternate cycles; there is another reason we will explain shortly. One of the ports, is capable of sending a single SPMD instruction to the 8 regular pipelines (remember the 32 threads are in lockstep logically, so there should certainly be enough for 8 FUs for a single cycle to get the same instruction from the same warp). The alternate cycle is restricted to issue to the SFUs in the cluster, each of which contains 4 FUs that are capable of executing FMUL instructions, and other logic that do more complex fixed functions (transcendental, interpolation, reciprocal, etc, etc).
Some simple instructions (mostly ALU instr) can complete in one cycle on any of the FU's within the regular pipelines. The more complex instructions that the regular pipelines (SP for NV speak) are capable of, such as multiply-add, and these would be the majority case, requires two cycles in the pipeline to complete; and so does the relatively complex FMUL instructions in each of the SFU's function blocks. This is the other reasons why, while the scheduler itself runs at full core clock, the issue ports to the pipelines and the SFUs only accepts at alternate cycles (you can look at it as the issue ports being run at half clock, although physically it's not the case). When the SPMD stream has instructions that are capable of taking advantage of this alternate clock alternate port scheduling (which NV mistakenly calls "dual issue"), such as when instruction stream MAD, FMUL, MAD, FMUL, MAD, FMUL ..., it is necessarily the case that 16 instructions can be excuted in 2 cycles; and so for the sake of the simplicity of the scheduler(and since in majority of the case an FU can only handle one instr per 2 cycles), the microarchitecture uses this type of schedule algorithm in the clusters.
So what NV terms "dual issue", what you probably got from their public presentations, and probably posted on a few internet sources is not related to dual issue in the traditional superscalar sense at all; it is only dual issue in respect to the restriction on the speed of the SPMD issue ports inside a cluster. I hope I'm making things a little more clear. I can delve into more details of how such uarchitectures work, but that might not be necessary, and might be beyond the scope of this forum.
This post is already too long, I'll answer the rest of yours in another one.
