R520 Running

Can't we get an adaptive soultion .


LIke 12x fsaa that will reduce down all the way to 2x depending on user set frame rates (if a user allways wants to be above 60 or 80 fps they can select that ) and the amount of samples each frame needs ?

 

Assuming the number of samples can be switched on the fly (which doesn't seem improbable given what ATi have done with T-AA), fps are usually so volatile that such a system would never be able to react in time. It'd probably jump rapidly into oscillation between min/max number of samples.

You could take a "dynamic average" (for want of a better phrase) over a short time delta, but it'd still be very difficult to avoid compounding sudden drops in fps by having the AA level set too high.

 

lets stay on subject......what do we know about r520?
i like this discussino u guys are having, but i am kinda lost in it....
is there anything confirmed...other the INQ rumors?

 

Well, nothing confirmed, but based on recent speculation here, Dave's excellent front page ramblings, Inq/Digitimes etc, past trends and common sense:

0.09u (low-k) @TSMC
Taped out about two months ago so first silicon probably back early this month
SM3.0
FP32
16P/8V
Shader core still based on R3x0/R4x0
Native PCIe and Rialto-bridged AGP versions
Max core clock in the region of 600-700MHz
Die size 250-300million transistors
256-bit, GDDR3/4-compatible memory interface
256-512MB memory at launch (GDDR3@1.2-1.4GHz?)
Possibly higher MSAA modes (8x?)
Multiple GPU capability
Bundled with Gabe Newell - "I like pie whilst I frag" - t-shirt

 

Slightly OT, but has anyone ever seen a "spit coffee/pop all over your monitor laughing" smiley out there? I really need one....

 

I'll bold things I doubt:

so it looks good. I'm thinking more pipelines rather than just a core boost, though. Rialto bridge for AGP systems for a part to debut Q2 05? I REALLY doubt it. REALLY REALLY doubt it. maybe for mid-end and below, okay, but high end? no. core clock seems high, especially if pipelines are increased. even if it is 600-700, though, it still seems high. FP32 and SM3.0 will probably bring a hefty increase in transistor count that .09 won't be able to overcome completely, so unless we're in for some dual-slot cooling or something like that, power consumption and cooling would probably prevent clock speeds from going over 625 or so.

the longer it takes to come out, the more likely 512 meg cards are. I'd be surprised if memory is over 650, though, given the limited supplies of all GDDR3 right now. higher AA mode is possible, although we'll see if it's a priority yet (it might be a refresh thing).

 

50/50 there may be a slight alteration to GDDR3 before GDDR4 comes out.

 

care to share the nature of this change...? GDDR3.5?

 

I've just heard a vague hint about something like GDDR3+, but don't know anything about it yet. Obviously, more bandwidth is going to be a must with faster parts.

 

I hope we're not looking at a voltage bump... also, this might just be me getting confused and all, but doesn't GDDR3 have slightly looser timings than DDR?

 

Wasn't the whole point of GDDR3 to bring DDR2 (high speeds) and DDR (low latencies) together?

 

Was it? I'm not sure. I thought the main reason was to lower voltages to (IIRC) 1.6v instead of 2.5v because DDR2 didn't scale as well as was expected...

 

I thought the main reason was to fix the termination scheme. The one used on GDDR2 limited reasonably attainable frequencies and consumed excessive power.

 

With such high estimated core frequencies, it's rather an "either/or" scenario. You can either have more SIMD channels and lower frequencies or you can have =/>600MHz with 4 quads. It's not only the cost that would be the milestone here, memory bandwidth is obviously too. Feeding ~10GPixels/sec is way easier than ~15GPixels/sec.

As for 8x MSAA, I hope you guys have anything better to suggest than a 4th loop....

 

I just had this crazy(?) idea last night. Could they make the chip to have 16VS&16PS pipes and make it so that every VS is connected to a single PS pipe?
It would be a step towards unified shader style design in a way I think. Any way this kind of design would work? (It would be massively unbalanced towards polygon power, but that's beside the point)

Seems to me that they can't have (much) more PS pipes going from 24bit->32bit and 2.0 -> 3.0 shaders, but they could allocate some more transistors to VS side of the chip.

 

The X850XT PE is already dual-slot cooling, why would the R520 not be?

Jawed

 

The way I understood unified shader architectures so far, one of their major advantages are the load balancing between PS/VS calls. If there's a very complex pixel shader with a very simplistic vertex shader in a scene (or the other way around), the pipeline won't stall in order for the longer shader to complete.

I don't see how your idea comes even close to that theoretical concept; in fact I'd consider 16VS units for a 4 quad chip as vastly overkill for the PC desktop market. Not only are the majority of the units going to sit around idle, but it would increase cost tremendously if we're talking about 16 VS3.0 MIMDs f.e. I doubt that there are going to be any cases where even on a unified shader architecture such as the Xenon VPU, the analogy between PS/VS calls will be 16:16; if yes then I'd figure they'd be extremely rare.

 

What about "advanced memory interface" and kaleidoscope (altho there has been at least one hint that might turn out to be 'aka' rather than 'and').

 

I think Kaleidoscope is something to do with display management or output QC.

As for the interface, there have been a few not-so-subtle hints that there might be some big internal changes (topological?). Lots of clues about if you want to take this a step further.

 

Oh, please do! I've seen two Wavey nuggets in threads I could point you at --what other clues are there?