ECC Support

AMD's Radeon HD 5870 can detect errors on the memory bus, but it can't correct them. The register file, L1 cache, L2 cache and DRAM all have full ECC support in Fermi. This is one of those Tesla-specific features.

Many Tesla customers won't even talk to NVIDIA about moving their algorithms to GPUs unless NVIDIA can deliver ECC support. The scale of their installations is so large that ECC is absolutely necessary (or at least perceived to be).

Unified 64-bit Memory Addressing

In previous architectures there was a different load instruction depending on the type of memory: local (per thread), shared (per group of threads) or global (per kernel). This created issues with pointers and generally made a mess that programmers had to clean up.

Fermi unifies the address space so that there's only one instruction and the address of the memory is what determines where it's stored. The lowest bits are for local memory, the next set is for shared and then the remainder of the address space is global.

The unified address space is apparently necessary to enable C++ support for NVIDIA GPUs, which Fermi is designed to do.

The other big change to memory addressability is in the size of the address space. G80 and GT200 had a 32-bit address space, but next year NVIDIA expects to see Tesla boards with over 4GB of GDDR5 on board. Fermi now supports 64-bit addresses but the chip can physically address 40-bits of memory, or 1TB. That should be enough for now.

Both the unified address space and 64-bit addressing are almost exclusively for the compute space at this point. Consumer graphics cards won't need more than 4GB of memory for at least another couple of years. These changes were painful for NVIDIA to implement, and ultimately contributed to Fermi's delay, but necessary in NVIDIA's eyes.

New ISA Changes Enable DX11, OpenCL and C++, Visual Studio Support

Now this is cool. NVIDIA is announcing Nexus (no, not the thing from Star Trek Generations) a visual studio plugin that enables hardware debugging for CUDA code in visual studio. You can treat the GPU like a CPU, step into functions, look at the state of the GPU all in visual studio with Nexus. This is a huge step forward for CUDA developers.


Nexus running in Visual Studio on a CUDA GPU

Simply enabling DX11 support is a big enough change for a GPU - AMD had to go through that with RV870. Fermi implements a wide set of changes to its ISA, primarily designed at enabling C++ support. Virtual functions, new/delete, try/catch are all parts of C++ and enabled on Fermi.

Efficiency Gets Another Boon: Parallel Kernel Support The RV770 Lesson (or The GT200 Story)
POST A COMMENT

416 Comments

View All Comments

  • Mr Perfect - Saturday, October 3, 2009 - link

    It looks like it safe... After about 37 pages.

    Good job though, it's actually been worse in Anandtech comments then it usually is on Daily Tech! Now that's saying something...
    Reply
  • Kougar - Friday, October 2, 2009 - link

    Hey Anand:

    Just wanted to say thanks for the article. Love the quotes and behind-the-scene views, and in general the ever so informative articles like this that just can't be found elsewhere. So, thank you!
    Reply
  • bobvodka - Friday, October 2, 2009 - link

    Someone earlier askes if supporting doubles was going to waste silicon, I don't think it will.

    If you look at the through put numbers and the fact that FP64 is half that of FP32 with the SFU disabled I suspect what is going on is that the FP64 calculations are being done by 2 cores at once with the SFU being involved in some way (given how it is decoupled from the cores there is no apprent good reason why the SFU should be disabled during FP64 operation).

    A comment was also made re:ECC memory.
    I suspect this wont make it to the consumer board; there is no good reason to do so and it would just cost silicon and power for a feature users don't need.

    Reply
  • Zool - Friday, October 2, 2009 - link

    Maybe the consumer board wont hawe ECC but it will be still in the silicon (disabled). I dont think that they will produce two different silicons just becouse of ECC. Reply
  • bobvodka - Friday, October 2, 2009 - link

    hmmm, you are probably right on that score and that might aid yield if they can turn it off as any faults in the ECC areas could be safely ignored.

    Chances of them using ECC ram on the boards themselves I would have said was zero simply due to cost :)
    Reply
  • halcyon - Friday, October 2, 2009 - link

    Same foundry, same process, much more transistors....

    Based on roughly extrapolating scaling from the RV870, how much bigger power draw would this baby have?

    The dollar draw from my wallet is going to be really powerful, that's for sure, but how about power?



    Reply
  • deeper - Friday, October 2, 2009 - link

    Well, not only is the GT300 months away but it looks like the card they showed off is a fake anyhoo, check it out at Charlie Demerjian's www.semiaccurate.com Reply
  • Zool - Friday, October 2, 2009 - link

    Could you pls delete majority of SiliconDoc replies and than this after them. Its embarassing to read them. Reply
  • Pirks - Friday, October 2, 2009 - link

    I call BS. How many people have 2560x1600 30-inchers? Two? Three? Main point - resolutions are _VERY_ far from being stagnated, they have SOOOOOOOOO _MUCH_ room for growth until 2560x1600 which right now covers maybe 1% of the PC gaming market. 90% of PC gamers still use low-res 1680x1050 if not less (I for one have 1400x1050, yeah shame on me, I don't want to spend $800 on hi-end SLI setup just to play Crysis in all its hi-res beauty, for.get.it.)

    Shame Anand, real shame.

    Otherwise top notch quality stuff, as always with Ananad.
    Reply
  • bigboxes - Friday, October 2, 2009 - link

    1680x1050 = low res??? Seriously? That's hi-def bro. I understand you can do better, but for my 20" widescreen it is definitley hi-def. Reply

Log in

Don't have an account? Sign up now