A More Efficient Architecture

GPUs, like CPUs, work on streams of instructions called threads. While high end CPUs work on as many as 8 complicated threads at a time, GPUs handle many more threads in parallel.

The table below shows just how many threads each generation of NVIDIA GPU can have in flight at the same time:

  Fermi GT200 G80
Max Threads in Flight 24576 30720 12288

 

Fermi can't actually support as many threads in parallel as GT200. NVIDIA found that the majority of compute cases were bound by shared memory size, not thread count in GT200. Thus thread count went down, and shared memory size went up in Fermi.

NVIDIA groups 32 threads into a unit called a warp (taken from the looming term warp, referring to a group of parallel threads). In GT200 and G80, half of a warp was issued to an SM every clock cycle. In other words, it takes two clocks to issue a full 32 threads to a single SM.

In previous architectures, the SM dispatch logic was closely coupled to the execution hardware. If you sent threads to the SFU, the entire SM couldn't issue new instructions until those instructions were done executing. If the only execution units in use were in your SFUs, the vast majority of your SM in GT200/G80 went unused. That's terrible for efficiency.

Fermi fixes this. There are two independent dispatch units at the front end of each SM in Fermi. These units are completely decoupled from the rest of the SM. Each dispatch unit can select and issue half of a warp every clock cycle. The threads can be from different warps in order to optimize the chance of finding independent operations.

There's a full crossbar between the dispatch units and the execution hardware in the SM. Each unit can dispatch threads to any group of units within the SM (with some limitations).

The inflexibility of NVIDIA's threading architecture is that every thread in the warp must be executing the same instruction at the same time. If they are, then you get full utilization of your resources. If they aren't, then some units go idle.

A single SM can execute:

Fermi FP32 FP64 INT SFU LD/ST
Ops per clock 32 16 32 4 16

 

If you're executing FP64 instructions the entire SM can only run at 16 ops per clock. You can't dual issue FP64 and SFU operations.

The good news is that the SFU doesn't tie up the entire SM anymore. One dispatch unit can send 16 threads to the array of cores, while another can send 16 threads to the SFU. After two clocks, the dispatchers are free to send another pair of half-warps out again. As I mentioned before, in GT200/G80 the entire SM was tied up for a full 8 cycles after an SFU issue.

The flexibility is nice, or rather, the inflexibility of GT200/G80 was horrible for efficiency and Fermi fixes that.

Architecting Fermi: More Than 2x GT200 Efficiency Gets Another Boon: Parallel Kernel Support
Comments Locked

415 Comments

View All Comments

  • Inkie - Saturday, October 3, 2009 - link

    Not that I really want to support SD here, but there was working silicon there. It's kind of weird that many sites fail to mention this. Instead, they focus on the mockup.
  • SiliconDoc - Thursday, October 1, 2009 - link

    Go read a few articles on how a card is developed, and you'll have the timeline, you red rooster retard.
    I mean really, I'm talking to ignoramussed spitting cockled mooks.
    Please, the articles are right here on your red fan website, so go have a read since it's so important to you how people act when your idiotic speculation is easily and absolutely 100% incorrect, and it's PROVEABLE, the facts are already IN.
  • gx80050 - Friday, October 2, 2009 - link

    You're a fucking friendless loser who should have died on 9/11. Fucking cunt
  • monomer - Friday, October 2, 2009 - link

    In reply to your original link, here's a retraction, of sorts:

    http://www.fudzilla.com/content/view/15798/1/">http://www.fudzilla.com/content/view/15798/1/

    The card Nvidia showed everyone, and said was Fermi is in fact a mock-up. Oh well.
  • silverblue - Thursday, October 1, 2009 - link

    What facts? What framerates can it manage in Crysis? What scores in 3DMark? How good it is at F@H?

    Link us, so we can all be shown the errors of our ways. It's obvious that GT300 has been benchmarked, or at least, it's only obvious to you simply because the rest of us are on a different planet.

    You call people idiots, and then when they reply in a sensible manner, you conveniently forget all that and call them biased (along with multiple variations on the red rooster theme). You're like a scratched vinyl record and it's about time you got off this site if you hate its oh-so-anti-nVidia stance that doesn't actually exist except in your head.

    Prove us wrong! Please! I want to see those GT300 benchmarks! Evidence that Anandtech are so far up AMD's rear end that nothing else is worth reporting on fairly!
  • Zool - Thursday, October 1, 2009 - link

    GTX285 had 32 ROPs and 80 TMUs for aorund the same bandwith like 5870 with same 32 ROPs and 80 TMUs. Dont be stupid. GTX will surely need more ROPs and TMUs if they want to keep up with graphic even with the GPGPU bloat.
  • Totally - Wednesday, September 30, 2009 - link

    it's 225GB/s not 230.4/s

    230400/1024 = 225

    I'm afraid your bad at math.
  • Lightnix - Thursday, October 1, 2009 - link

    Nope, just really bad at remembering that those prefixes mean 1024 at like 1 in the morning.
  • Lonyo - Wednesday, September 30, 2009 - link

    You assume that they will use GDDR5 clocked at the same speed as ATI.
    They could use higher clocked GDDR5 (meaning even more bandwidth), or lower clocked GDDR5 (meaning less bandwidth).
    There's no bandwidth comparison because 1) it's meaningless and 2) it's impossible to make an absolute comparison.

    NV will have 50% more bandwidth if the speed of the RAM is the same, but it doesn't have to be the same, it could be higher, or lower, so you can't say what absolute numbers NV will have.

    I could make a graph showing equal bandwidth between the two cards even though NV has a bigger bus, or I could make one showing NV having two times the bandwidth despite only a 50% bigger bus.
    Both could be valid, but both would be speculative.
  • Calin - Thursday, October 1, 2009 - link

    Also, there could be a chance that the Fermi chip doesn't need/use much more bandwidth than the GT200. Available bandwidth does not performance make

Log in

Don't have an account? Sign up now