NVIDIA Fermi: Architecture discussion

I'm sure they can, but ATI has parts in the mainstream segment as well, and the relative yields/price/performance ratios are still going to be in their favor, regardless of how nvidia decides to scale their architecture. Basically, at any given performance point, the GF100 part will probably be more expensive to *make*, just like the G200 vs R770 situation.

You can do many more things with the GF100, and it's use in HPC seems pretty awesome, but for mainstream gaming and consumer use, the market needs can't be met at the same price points without accepting a lower margin. That's generally not a good thing to do if you want to be competitive in that market.

 

I can't think of a single transistor in G80 that's CUDA specific. GT200 manages to squeeze in some double precision. Maybe I'm just tired and forgetful

Jawed

 

That's simple, AMD put in really cheap DP. Insanely cheap. It isn't very good, either. Just adequate if you're willing to work around it.

Jawed

 

That's a good point, but GF100 DP is prolly "real man's" DP, not the half-cocked ATI variant.

Subnormals and exception processing on GF100 would appear to be much better than on Larrabee too. Do all these things make GF100 compelling?

Does the lack of SSE compatibility in Larrabee make it a dead duck in HPC?

Jawed

 

32 bit MUL wants to produce a 64-bit result in general - that's still pretty expensive. If it wasn't, we'd have more INT MULs in earlier GPUs.

I'm not willing to believe that. How would DP function if the bandwidth wasn't there, since it uses both units concurrently.

We have no details on the ATI 24-bit INT-MUL - is that just the 24 lowest bits? I suspect its for addressing type calculations.

Jawed

 

What's so inefficient about putting circular append buffers between producer/consumer kernels and branching to consumers when they have full warps? It takes storage, but running strands on Larrabee with only a few active fibers won't be efficient either ... the storage is a necessity.

 

Huh? I can *maybe* see them dropping ROPs but TMUs?? Where do you get that impression?

 

24-30th August, apparently.

Jawed

 

So you think adding full IEEE compliance for DP will hurt AMD (a lot) when it takes that step?

 

To summarize, (in no particular order)

1) Real DP, no really, full IEEE dp without apologies

2) function pointers, recursion

3) C++ style new delete, exception handling

4) a c++ debugger for vs, dunno if there will be a cuda fortran compiler

5) cpu style caches for better performance in irregular workloads

6) more int32 performance than what anybody needs. Why? Why?

7) More shared memory.

8) simultaneous kernel execution, compute, cpu->gpu memcpy, gpu->cpu memcpy, all 3 can go in parallel

9) full ECC, all the way from reg file to off chip ram

10) unified mem space, but memspace must be known at compile time.

11) supports both DDR3 and GDDR5. Why bother with DDR3 if you have spent trannies and effort to hack in ECC on GDDR5?

Have I left out anything?

 

It has a read/write cache on the memory bus, very nice ... but that's not really a CPU style architecture. CPUs tend to be read/write and coherent across the entire cache hierarchy.

Because they have huge multipliers for DP around anyway, 50% of which will be idle when not doing DP ... no point in sweating the small stuff.

Have they even said they would do ECC on GDDR5?

 

It's inferior to Larrabee, which has integer vector operations (and an additional scalar one as well).

FP and INT share a data path (and possibly more hardware for all we know) and cannot coissue. Having something like that thrown back on the shader core would effectively end the decoupled texturing that lead to such efficiencies in earlier GPUs. I'd worry that shader work couldn't progress until texturing was done.

How did you derive this rate for Larrabee, particularly the Z rate?

So one or more threads on the core will wait around for the producer to complete, then pick up, or is it multiple working threads, then a context switch to pull in a consumer?

 

Shared memory?

 

Sorry, but what makes you think that Fermi is any more or less IEEE than Cypress?

 

I'm sure Cypress would take exception to the claim it is isn't fully compliant, if it can.

 

If G92 vs R670/G200 vs R770 has taught us anything, it's not how expensive it is to make, it's how well it performs.

 

Probably not exception handling outright, ie. with the hardware fully handling the branching/states/etc. with no overhead when the exceptions don't occur ... but as long as the flags are there they should be able to support exceptions with a performance hit (not a huge one either AFAICS).

 

edit: why do I even bother, believe whatever FUD you want to believe

 

What hardware?

 

Which demo was that? And why was the fluid demo reportedly running on G2xx-hardware if there was real hardware to be used?