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

  • AlexWade - Wednesday, September 30, 2009 - link

    How long have you been working for NVidia?
  • taltamir - Thursday, October 1, 2009 - link

    don't insult nvidia by insinuating that this zealot is their employee
  • dzoni2k2 - Wednesday, September 30, 2009 - link

    What the heck is wrong with you SiliconDoc?

    Since when is memory bandwidth main indicator of performance?!

    For all I care Fermis memory bandwidth can be 999GB/s but what good is that if it's not used?
  • SiliconDoc - Friday, October 2, 2009 - link

    I'm sure "it won't be used" because for the very first time "nvidia will make sure it "won't be used" becuase "they designed it that way ! " LOL
    --
    You people are absolutely PATHETIC.

    Now the greater Nvidia bandwith doesn't matter, because you don't care if it's 999, because... nvidia failed on design, and "it won't be used!"
    ROFLMAO
    Honestly, if you people heard yourselves...
    I am really disappointed that the bias here is so much worse than even I had known, not to mention the utter lack of intellect so often displayed.
    What a shame.
  • PorscheRacer - Wednesday, September 30, 2009 - link

    Exactly! R600 had huge bandwidth but couldn't effectively use it; for the msot part. Is this huge bandwdth the GF300 has only able to be used in cGPU, or is it able to be used in games, too? We won't know till the card is actually reviewed a long while from now.
  • SiliconDoc - Wednesday, September 30, 2009 - link

    What a joke. The current GT200 responds in all flavors quite well to memory clock / hence bandwith increases.
    You know that, you have been around long enough.
    It's great seeing the reds scream it doesn't matter when ati loses a category. (no actually it isn't great, it's quite sickening)
  • SiliconDoc - Wednesday, September 30, 2009 - link

    Yes of course bandwith does not really matter when ati loses, got it red rooster. When nvidia is SO FAR AHEAD in it, it's better to say "it's not double"...LOL
    ---
    WHAT IS WRONG WITH YOU PEOPLE AND THE AUTHOR IS THE REAL QUESTION!
    --
    What is wrong with you ? Why don't you want to know when it's nvidia, when it's nvidia a direct comparison to ati's card is FORBIDDEN !
    That's what the author did !
    It was " a very adept DECEPTION" !
    ---
    Just pointing out how you get snowballed and haven't a clue.
    Rumors also speculated 4,000 data rate ddr5

    4000x384/8 - 192 bandwith, still planty more than 153 ati.

    CLEARLY though "not double 141" (nvidia's former number also conveniently NOT MEWNTIONED being so close to 153/5870 is EMBARRASSING) - is 282...
    --
    So anand knows it's 240, not quite double 141, short of 282.
  • DigitalFreak - Wednesday, September 30, 2009 - link

    Looks like SnakeOil has another alias!
  • therealnickdanger - Wednesday, September 30, 2009 - link

    Agreed. That was refreshing!
  • mapesdhs - Wednesday, September 30, 2009 - link


    Blimey, I didn't know Ujesh could utter such things. :D When I knew
    him in 1998 he was much more offical/polite-sounding (he was Product
    Manager for the O2 workstation at SGI; I was using a loaner O2 from
    SGI to hunt for OS/app bugs - Ujesh was my main contact for feedback).

    The poster who talked about availability has a strong point. My brother
    has asked me to build him a new system next week. Looks like it'll be
    an Athlon II X4 620, 4GB RAM, 5850, better CPU cooler, with either an
    AM3 mbd and DDR3 RAM or AM2+ mbd and DDR2 RAM (not sure yet). By heck
    he's going to see one hell of a speed boost; his current system is a
    single-core Athlon64 2.64GHz, 2GB DDR400, X1950Pro AGP 8X. :D My own
    6000+ 8800GT will seem slow by comparison... :|

    Ian.

Log in

Don't have an account? Sign up now