R520 Running

[hovz]

just to add, the r520 is basically just a r420 with sm 3.0 and higher precision. the shader core will likely be almost the same. the pipes obviously cant be doubled in number, clock speed cant be raised too much higher, memory speed has hit sort of a brick wall. where exactly can they get substantially higher performance.

 

[MuFu]

just to add, the r520 is basically just a r420 with sm 3.0 and higher precision. the shader core will likely be almost the same. the pipes obviously cant be doubled in number, clock speed cant be raised too much higher, memory speed has hit sort of a brick wall. where exactly can they get substantially higher performance.

Memory interface/internal topology improvements, more VS units (completely new VS?). As long as fast enough memory is available, worst case it'll scale with clockspeed vs 420 (~25%) and it'll probably be quite a bit faster in bandwidth or geometry-limited situations.

 

[hovz]

just to add, the r520 is basically just a r420 with sm 3.0 and higher precision. the shader core will likely be almost the same. the pipes obviously cant be doubled in number, clock speed cant be raised too much higher, memory speed has hit sort of a brick wall. where exactly can they get substantially higher performance.

Memory interface/internal topology improvements, more VS units (completely new VS?). So as long as fast enough memory is available, worst case it'll scale with clockspeed vs 420 (~25%) and it'll probably be quite a bit faster in bandwidth or geometry-limited situations.

good news for 3dmark 05 fans

 

[nelg]

they can barely produce high end r420/r480 as it is. you think in 4 or 5 months from now they are going to launch a chip substantially faster than what they cant even produce now?

Their sales look pretty good. Perhaps cannibalized be the OEM market though.

if they could so easily double the performance of the r420 4 to 5 months from now they wouldnt have even rereleased the r420 some 7 months after it originally came out.

Maybe the r480 was released to improve yields and add to the supply of chips.

and finally its not at all likely that they can substantially increase performance over a product they can barely get to market in a timeframe of 1 year.

Why not? The development of the r520 (and what it shares with the original r400) was started before the release of the R300.

just to add, the r520 is basically just a r420 with sm 3.0 and higher precision. the shader core will likely be almost the same. the pipes obviously cant be doubled in number, clock speed cant be raised too much higher, memory speed has hit sort of a brick wall. where exactly can they get substantially higher performance

Care to share your sources or is this just your speculation?

 

[Ostsol]

Is it at worthwhile to ask where in the core support for branching might be? Is it integral to the pipeline design or is there an instruction cache and instruction pointer that remains outside?

 

[gordon]

they can barely produce high end r420/r480 as it is. you think in 4 or 5 months from now they are going to launch a chip substantially faster than what they cant even produce now?

why wouldnt they release a marginally faster chip? they just released a chip that was released MONTHS ago basically unchanged and raised the price 50 bucks.

if they could so easily double the performance of the r420 4 to 5 months from now they wouldnt have even rereleased the r420 some 7 months after it originally came out.

and finally its not at all likely that they can substantially increase performance over a product they can barely get to market in a timeframe of 1 year.

Not quite sure why the retail availability of the ultra high end R4x0 products would dictate what R520 is. If you believe the rumors of its tapeout a month or two ago, the chip should have already been well into the finishing touches when R420 was released.

ATI also has competitors, so they still do have to do the competition thing (not a monopoly yet). If anything the strength of the NV40 versus the R420 would increase the possibility that ATI would seek to strengthen the R520 a bit.

I also never said they would double performance but we probably could expect a substantial increase in high resolution situations on the more advanced games out. By high resolution situations I mean 1600x1200 or 2048x1536 with high levels of aa and af.

 

[Ailuros]

I also never said they would double performance but we probably could expect a substantial increase in high resolution situations on the more advanced games out. By high resolution situations I mean 1600x1200 or 2048x1536 with high levels of aa and af.

You're sure you aren't overestimating things with the last resolution? Besides I hope you are aware what kind of video bandwidth and size a monitor (currently CRT) exactly needs to display flawlessly in 2048*1536.

 

[hovz]

they can barely produce high end r420/r480 as it is. you think in 4 or 5 months from now they are going to launch a chip substantially faster than what they cant even produce now?

why wouldnt they release a marginally faster chip? they just released a chip that was released MONTHS ago basically unchanged and raised the price 50 bucks.

if they could so easily double the performance of the r420 4 to 5 months from now they wouldnt have even rereleased the r420 some 7 months after it originally came out.

and finally its not at all likely that they can substantially increase performance over a product they can barely get to market in a timeframe of 1 year.

Not quite sure why the retail availability of the ultra high end R4x0 products would dictate what R520 is. If you believe the rumors of its tapeout a month or two ago, the chip should have already been well into the finishing touches when R420 was released.

ATI also has competitors, so they still do have to do the competition thing (not a monopoly yet). If anything the strength of the NV40 versus the R420 would increase the possibility that ATI would seek to strengthen the R520 a bit.

I also never said they would double performance but we probably could expect a substantial increase in high resolution situations on the more advanced games out. By high resolution situations I mean 1600x1200 or 2048x1536 with high levels of aa and af.

therea a difference between what ati would like to do, and what it is feasible for them to do when you consider manufacturing costs.

 

[Wunderchu]

Hmmm...I haven`t heard r520 will be made in 90 Low-k...it`s likely to be made in ``pure`` 90nm tech.

AFAIK, it is assumed that any 90nm process at TSMC at the moment, will be low-k...........


DaveBaumann posted in this thread: ( http://www.beyond3d.com/forum/viewtopic.php?t=11986&postdays=0&postorder=asc&start=0 ) back in April,

From TSMC, yes. There will not be non low-k variants of 90nm though (at least, at this point in time).

TSMC. At the moment they are only offering low-k 90nm

As I said, according to TSMC's reasearch which was told to us two weeks ago there were no foundries offering 90nm without low-k.

 

[Dave Baumann]

IIRC UMC are offering a non-low-k 90nm option, but there is no idication that ATI are using it and everything suggests they are using TSMC. I think their success with 130nm low-k is the reason they are attempting to go ahead with 90nm straight away.

 

[mustrum]

Really? You think they're going thru all that trouble for a 20-30% improvement? Sounds not too worth it if that's all it is. I'm hoping for at least 100% improvement over the X850XT. Sheesh.

twice the performance would mean not only adding the trannys for sm3.0 support as well as 32bit color, while also adding the trannys for the new dynamic branching enhancement rumors that are circulating, AND either doubling the the number of pipelines or doubling the clockspeed of the r420 (or some ratio of the two). thats quite a bit of transistors even for the 90nm process, considering its the first one they've ever done.

They made it with R300... so why not?

Yeah but all they did basically is doubling the pipes and upping the clock rate.
If they do that now we'd look at a 32 pipe card. Such a complex chip isn't possible atm i think. At least not at the needed clockrate for a affordable price.

 

[_xxx_]

Would you please explain what a "needed" clockrate is?

 

[jvd]

doubling the pipelines and keeping the clock speed the same would net you double the performance. 16640mpixel fillrate compared to the 8320megapixels of the x800xt pe .

Of course you'd need even more bandwidth than you have now , almost surely needing to go to a 512bit bus .

 

[Ostsol]

There's also a need to consider whether the additional texel fillrate is needed right now. Should they worry so much about bandwidth, or put more emphasis on instruction throughput? In that case, the pipeline increase is not so critical as clockspeeds might be, or having longer pipelines with more ALUs. To put it into perspective: is Epic's UE3.0 demo bandwidth limited or shader limited?

 

[gordon]

You're sure you aren't overestimating things with the last resolution? Besides I hope you are aware what kind of video bandwidth and size a monitor (currently CRT) exactly needs to display flawlessly in 2048*1536.

No, no I'm not :/. 21" and higher monitors capable of those resolutions have been on the market for a while now and they're not that rare. I've only seen a few actually game at that resolution though for obvious reasons. Would be nice to get a goo gaming experience at that resolution though, as it doesnt even seem current cards can deliver that in todays games.

 

[Ailuros]

You're sure you aren't overestimating things with the last resolution? Besides I hope you are aware what kind of video bandwidth and size a monitor (currently CRT) exactly needs to display flawlessly in 2048*1536.

No, no I'm not :/. 21" and higher monitors capable of those resolutions have been on the market for a while now and they're not that rare. I've only seen a few actually game at that resolution though for obvious reasons. Would be nice to get a goo gaming experience at that resolution though, as it doesnt even seem current cards can deliver that in todays games.

I do own a 21" CRT and you don't actually need much of antialiasing in that case since the monitor is doing some sort of "upsampling" by itself.

The manufacturer lists only the horizontal dot pitch, but I'm guessing that the vertical dot pitch must be at 0.25.

355mm/0.25 = 1420

In other words even 1920*1440 is already "stretched" for such a monitor. Even with a 340MHz video bandwidth it yields only a 75Hz refresh rate, which is perfectly tolerable on one side, the viewable space is just too small for such a resolution. You can read any form of text or handle 2D flawlessly up to 1600*1200, above that: guess again.

Yes current 256MB high end cards can handle under most occassions 2xMSAA in 2048, but performance still is way behind what I'd consider playable.

Now I personally had the impression that CRTs are a dying breed (and along some people with similar preferences to me). I do hope that you don't mean purely hypothetical TFT/LCDs with a 2048 native resolution on the other hand.

 

[AndrewM]

To put it into perspective: is Epic's UE3.0 demo bandwidth limited or shader limited?

Using floating point render targets, you need lots of bandwidth. I'd say that they need a lot of shader power for UE3 as well.

So, Both

 

[Reverend]

To put it into perspective: is Epic's UE3.0 demo bandwidth limited or shader limited?

Using floating point render targets, you need lots of bandwidth. I'd say that they need a lot of shader power for UE3 as well.

So, Both

What does "shader limited" mean?

Are we talking about framerate of a tech demo being limited by memory bandwidth and/or hardware shader capabilities? Why should we care either way?

 

[hovz]

when it comes down to it, i dont think r520 will be much faster than whats avalible today. im sure it will have more features that will be used in 2006, but i dont see it benefiting the end user much if they already have an r420.

 

[Ostsol]

What does "shader limited" mean?

Basically, is the limit one of instruction execution times or of memory access? Are shaders so long that the time spent executing those instructions doesn't allow bandwidth to be saturated?