[Ailuros]

Originally Posted by nAo

You clearly haven't read what I wrote about data transfer errors. We are dealing with GDDR5, it won't fail, it will scale badly or even impact perf. Moreover no app is entirely ALU limited or bw limited, bottlenecks are dynamic and constantly change while rendering a single frame.
BTW..not just talking about the memory modules 'failing', the GDDR5 interface can fail as well.

Albeit I don't know anything yet but assuming the 384bit bus for GF100 is true, what guarantees that we might see something similar here too?

[rpg.314]

I on the other hand believe that CPU style caches dont scale. LRB's rendering pipeline is an ample proof of that. We'll need scratch pad memories, just like cell/gpu's of today. However, the one thing that I'll change over cell is to allow vector scatter gather from global memory as well, and not just async. dma's.

Cell programmers might be banging their heads against walls, stones etc. But gpu programmers have got on pretty fine in the last 2.5 years on CUDA.

[nAo]

Originally Posted by rpg.314

. But gpu programmers have got on pretty fine in the last 2.5 years on CUDA.

If you believe that you haven't read enough CUDA based research papers
edit: sooner or later nvidia & ati will add proper coherent r/w caches to their architectures, it's just a matter of time.

[FUDie]

Originally Posted by nAo

You clearly haven't read what I wrote about data transfer errors. We are dealing with GDDR5, it won't fail, it will scale badly or even impact perf. Moreover no app is entirely ALU limited or bw limited, bottlenecks are dynamic and constantly change while rendering a single frame.

Yes, I did read what you wrote and I do understand it. And nothing you say contradicts the fact that Crysis scaled better with engine clock. It doesn't matter if the memory wasn't scaling as well due to errors: 9% engine clock gave 5% performance boost. If both engine and memory were increased by 9% the maximum gain we'd expect would be 9%. So 9% memory clock increase could give at most 4% more performance.

Engine clock is having a larger impact here. Note that engine speed regulates more than just ALU speed, it also controls ROP performance, vertex rates, etc.

-FUDie

[rpg.314]

Originally Posted by nAo

If you believe that you haven't read enough CUDA based research papers

May be. But I'd like to see someone using r/w coherency of caches on a say O(50) core chip with high performance to be convinced otherwise.

edit: sooner or later nvidia & ati will add proper coherent r/w caches to their architectures, it's just a matter of time.

I am in the software managed caches camp for now. r/w coherent caches hurt more than the help in the O(50) cores regime, as your compute increases as O(p) but your communication increases by O(p^2).

[nAo]

Originally Posted by rpg.314

your communication increases by O(p^2).

With naive/simple hw implementations.

[rpg.314]

May be it is possible to reduce the O(p^2) to something lower, but I am still waiting for something that uses the r/w coherency of caches on an O(50) core chip with high performance.

[Rys]

Originally Posted by Anteru

Seriously, if Rys is already doing diagrams of GF100 (while those for HD5k are still not out yet?), I'll definitely wait for the GF100 before deciding where to sink my money.

Those for HD 5870 are done, and were done before I started work on GF100 (thanks Alex!). We'll publish on it soon.

[Davros]

Originally Posted by Ailuros

the 384bit bus for GF100 is true,

GF100 ? where did this come from I know about G300, but Gf100 ???

edit: and Gt212 what the bloody hell is that ?

[Dr Evil]

Originally Posted by Davros

GF100 ? where did this come from I know about G300, but Gf100 ???

Go back to post nr. 2548 and read forward.

[AnarchX]

GPU specifications
This is the meat part you always want to read fist. So, here it how it goes:
* 3.0 billion transistors
* 40nm TSMC
* 384-bit memory interface
* 512 shader cores [renamed into CUDA Cores]
* 32 CUDA cores per Shader Cluster
* 1MB L1 cache memory [divided into 16KB Cache - Shared Memory]
* 768KB L2 unified cache memory
* Up to 6GB GDDR5 memory
* Half Speed IEEE 754 Double Precision

BSN

[trinibwoy]

What makes a single unit important is the fact that it can execute an integer or a floating point instruction per clock per thread.

[MfA]

built-in ECC features inside the GDDR5 SDRAM memory

Is he just being disingenuous here or does he still don't get it will generally only corrects transfer errors?

[Ailuros]

Originally Posted by Davros

GF100 ? where did this come from I know about G300, but Gf100 ???

edit: and Gt212 what the bloody hell is that ?

GT212 was IMHO a 40nm/D3D10.1 project which would had been a pretty dumb release considering that it also had a 384bit bus and 32SPs/cluster. It wouldn't had come close to GF100 though but most likely a future performance iteration of it. I'd say that if they had any common sense when they cancelled that project they moved its human resources into a GF10x performance GPU project.

Since you're asking questions I hope now some come can understand why the intentional false information in supposed roadmaps. They just "named" the D12U something like GTX280 1.5GB.

[rpg.314]

Isn't there supposed to be 32 kb shared mem per block in dx11?

[DegustatoR]

Originally Posted by rpg.314

Isn't there supposed to be 32 kb shared mem per block in dx11?

48>32?
Ah, I see, it's Theo again.
He's talking about L1 cache there. Considering there is 1 MB of memory total and 16 KB L1 per SM and 16 SMs (512/32=16) how do you get to 1 MB from 16x16KB?

[trinibwoy]

Originally Posted by 3dilettante

Maybe it could happen, though like Charlie I would question whether it would be wise to try to out-Larrabee Larrabee.

Looks like that's exactly what they're trying to do. Strange that there's no mention of any graphics specific bits so far. Not saying there aren't any but the focus seems to have veered sharply away from graphics.

A clean-sheet design that would basically abandon a huge chunk of the G80-GT200 framework would take time and resources to bring about. Given the time cycles for something like that, the roughly four years since the completion of G80 (assuming GT200's somewhat underwhelming improvements meant it was a secondary effort) would be a frighteningly tight timeline to architect a general purpose VLSI architecture.

That's true, but the same could be said for G71->G80 which was an even bigger change. Though they are trying to do more stuff now which could have put a strain on resources.

A big problem I see, as was noted in the discussion concerning the latency of Nvidia's atomic ops, was how the read-write-read process for GPUs with their read-only caches was so very long. As far as general computation is concerned, the rearchitecting of how caches interact would be something Nvidia would be interested in looking at...

It's probably safe to assume that if they're serious about computing, performance of atomics would have been high on their todo list. Side question - are the existing caches on GPUS generally useful for non-texture data (not referring to the specialized caches like PTVC)?

[trinibwoy]

Originally Posted by DegustatoR

48>32?

Heh, where did you see 48? Theo didn't mention it

Ah, I see what you did thar! 1024/16-16=48

[Rys]

Originally Posted by DegustatoR

Considering there is 1 MB of memory total and 16 KB L1 per SM and 16 SMs (512/32=16) how do you get to 1 MB from 16x16KB?

There isn't 16KB of L1 per SM.

[DegustatoR]

Originally Posted by Rys

There isn't 16KB of L1 per SM.

There might be -)

[fellix]

Or is it 32KB per 16-wide SM (two in a cluster) for a grand total of 512 SPs in 16 clusters and 1024KB array?!

[trinibwoy]

As you can read for yourself, the GT300 packs three billion transistors of silicon real estate, packing 16 Streaming Multiprocessor [new name for former Shader Cluster] in a single chip. Each of these sixteen multiprocessors packs 32 cores

What's he talking about? An SM previously referred to each independent 8-wide SIMD of which there are 30 in GT200. He's referring to each SM as being 32-wide and only having 16 of them per chip. Is it safe to assume he's mucking up the terminology, the architecture really has changed, or he's making up the whole thing?

[Rys]

It really has changed. I can't say (well I could) if Theo's right or not, but GF100 is not terribly GT200-like in places. All will be revealed later today anyway, not long to go now.

[trinibwoy]

http://www.fudzilla.com/content/view/15741/1/

Yep, so Fuad says as well. JHH will give us the business during his keynote at 1pm EST. Delays aside, it's good to know we'll have something new to dissect over the next few months

[Vincent]

Originally Posted by trinibwoy

http://www.fudzilla.com/content/view/15741/1/

Yep, so Fuad says as well. JHH will give us the business during his keynote at 1pm EST. Delays aside, it's good to know we'll have something new to dissect over the next few months

My present next year