The NEXT LAST R600 Rumours & Speculation Thread

One could argue that we all make our contribution.
I'm sure almost everyone on thes boards, and many other as well, does his/her daily check of Fudzilla and the Inq for a freash load of nonsense, and some will go as far as looking for that rare gem of "real info", providing our beloved entertainer with some nice ad revenue.
He's got a pretty safe business model going, I'd say. Post a lot of crap and people will come and read it, if for nothing else to have some fun.
Go Fudo!

 

I don't..

Next

 

Actually, the tent kernel is very cheap (and simple) -- generally one MUL op per sample address, eg. linear f(x), but the meaning point here is namely the steep weighting toward the pixel center, counter-acting to the outer edge, thus suppressing the blur (d)effect, but leaving enough residual colour gradients.
Nevertheless, I still want my precious Gauss kernel, some day in a DX10 driver release, maybe.

BTW, I expect very frenzy & detailed R600 analysis here, in B3D.

 

Eh? G80 has 16 8-way ALUs, each of which has a 2-way SF unit. There's your instruction granularity there.

Reading across the entire unified shader, R600 has a maximum of 20 distinct instructions in flight at a time (ignoring pipeline length): 4 units with 5 instructions. G80 has 32 distinct instructions: 16 units with 2 instructions.

How many different instructions can the 4 skinny ALUs do?:

• NOP
• ADD, MAD, MUL, SUB ...
• integer ADD, MAD, MUL, SUB ...
• binary ops (<<, >>, |, &, !),
• format conversions: fp<->uint<->int and 32<->16 variants (can't remember if there's a 24-bit variant)

can't think of anything else. That should fit in 20-bits, as 4-way x 5-bits and 12 bits to cover the SF gubbins on top of that lot in the fatboy ALU.

Jawed

 

fuad's A12 story just recycles what inq posted a couple of weeks back about going from A12 to A14 for the 2600...

The weird thing is.. those 2600's don't have a PCIe power connector but the ones in crossfire on AMD's forum do. One could argue that AMD went the extra mile on a re-spin to bring power requirements down a notch

 

I was only cautioning that it may not look like a teepee kind of tent. It might have a flat top and steep sides or a flat top and stepped sides.

Jawed

 

That covers the instruction type. What about the register selection? If each is doing a MAD and they are truly independent, you're looking at 3 operands and 1 destination * 5 = 20 register selections. If the register file is 32 deep, you're looking at 100 bits just for for that.
But that's only be the case for a MAD.

It wouldn't surprise me if a MAD instruction will still have some restrictions wrt register dependence.

 

I'm coming with Test Drive Unlimited Gift

1/R600XT, default E6600, default R600XT, ALL MAX 4xAA+HDR (1280x1024)
http://www.chiphell.com/attachments/month_0704/20070430_0400fa82c37352d946d3L3kMK47f6XI8.jpg

http://www.chiphell.com/attachments/month_0704/20070430_c75ef0d929375639ae83W9YksBRHKU2s.jpg

2/3.36g 6300 + x1950xtx, no game in setting info (1280x1024)
http://www.chiphell.com/attachments/month_0704/20070430_5bd953e4fed00463d6e3dhLNdgeZ0N2n.jpg

3/3.52G E6400 2GB ram 660/2200 8800GTX ALL MAX 4xAA +HDR (1280x960)

http://www.chiphell.com/attachments/month_0704/20070430_9372aaadc1957f360411Nkow9FjyyONs.jpg

more 3.52G E6400 2GB ram 660/2200 8800GTX (1280x960) pics:
http://we.pcinlife.com/thread-733559-1-1.html
http://we.pcinlife.com/thread-733065-1-1.html

Mod: Don't inline link images of that size!

 

Yes, the R600XT can co-issue 5 vectors/scalars, and in some cases R600XT is over 2x faster than 8800 GTX.

Test instruction set (length 384, no texture fetch and 100 iterations)
MAD R0.xyz, R0, R0, R1;
MUL R2.x, R2, R3;
MAD R1.x, R1, R1, R3;
MAD R0.xyz, R1, R1, R0;
ADD R2.x, R1, R2;
MUL R3.x, R3, R1;


R600XT (co-issue 3 instructions) - 93,9277 GInstr/sec

8800 GTX - 39,1998 GInstr/sec

 

Since when is it possible to transmit digital audio via a DVI connector? Surely part of the reason HDMI exists at all is precisely that it adds to DVI the ability to transmit video and audio down the same cable?

 

From German site

 

The last doesn't seem official as the rest, wasn't the general impression that it has 16x32bit, not 8x64bit controllers?

 

Integer support only via the fat ALU?

 

Thanks! VLIW was the magic word I was looking for.

 

Honestly, not sure, I just reposted the images from www.3dcenter.de forum. The last image posted was by a different forum member than the first images.

 

The fat alu is probably the special function unit

2k internal ringbus,

 

It's not just registers for operands, though. It's also possible to have indexed constants. There are 16 constant arrays (actually that's just what can be bound to a shader), each constant can have 4096 entries and each entry can have 4 elements. I didn't realise you meant to include stuff beyond the type!

Also, it seems that R6xx will be able to directly read/write virtual memory addresses, which will be a chunk of bits. Maybe I've got the wrong end of the stick though and only TUs and RBEs can address memory.

Yeah, hurts my head. Hoping we'll get some nice detail on this.

In the past ATI has been very proud of the fact that its ALU pipeline has not had any operand fetch bandwidth restrictions. I kinda hope they've maintained that tradition.

Theoretically, R3xx...R5xx are all capable of fetching 5 vec4 operands per clock, to feed the MAD+ADD pipeline. But I've never seen it stated in such cold, hard terms. It was years before ATI admitted to the presence of the vec4 ADD unit in the R3xx-and-up ALU pipeline...

Jawed

 

that's for sure, but since they just mention "integer and logic ops support" it makes me think
that thesere ops are not orthogonal to any ALU. I might be wrong of course.

 

Well, the specs certainly look very yummy! And close to what Jawed and I originally speculated about! Only with a lot stricter scheduling.

So, it does seem to be a case of bad drivers, after all. If it delivers, it should surely dethrone the 8800 easily.


I think they have hidden a large operand cache on the chip, to store all those VLIW ops. Think about it: they need something in the order of a 128 bit word each clock for each ALU simply to keep it going.

 

Higher bandwidth and mandatory HDCP (over HDMI) support are some others that come to mind.