AMD: R9xx Speculation

It's not that AFR "sucks" per se, just that it's rather limited. It works well only when you have two symmetric GPUs. Consider that forthcoming AMD CPUs are going to have integrated graphics, and they'd love to use that for a little extra boost to graphics performance when you're using a discrete GPU. You certainly can't do AFR when you have a 4x or 8x or greater performance difference between the two GPUs.

It wouldn't surprise me to see ATI invest quite a bit in new forms of mutli-GPU rendering over the coming year.

No AFR does well and truly suck, IMO.

It still only has the control latency of whatever the single GPU FPS would be, while rendering more frames per second. So if a single GPU would do 20 fps, but with AFR you can do 35, you'd still only be inputing at 20 fps. Totally unacceptable for me.

Added to that some devs have even commented on having to not use AFR unfriendly rendering techniques as that would prevent any scaling of multi-GPU. Basically any situation where a following frame relies on the results of the previous frame. As you are basically rendering 2 frames nearly simultaneously. If one frame relies on the previous one, you can't start rendering it until that frame is done. Trying to remember which game it was in reference to, but one dev had to reduce graphical effects so that AFR could work.

Not a programmer so that's just my layman's understanding of what they were saying.

Regards,
SB
 
It still only has the control latency of whatever the single GPU FPS would be, while rendering more frames per second. So if a single GPU would do 20 fps, but with AFR you can do 35, you'd still only be inputing at 20 fps. Totally unacceptable for me.
How do you figure that? It isn't like the same thing is drawn on both cards.
 
Added to that some devs have even commented on having to not use AFR unfriendly rendering techniques as that would prevent any scaling of multi-GPU. Basically any situation where a following frame relies on the results of the previous frame. As you are basically rendering 2 frames nearly simultaneously. If one frame relies on the previous one, you can't start rendering it until that frame is done. Trying to remember which game it was in reference to, but one dev had to reduce graphical effects so that AFR could work.

Not a programmer so that's just my layman's understanding of what they were saying.

Regards,
SB
It seems that GPU programmer's must parallelize as CPU programmer's have had to do for multi-core CPUs. So as with anything else in computing you parallelize if you want the best possible performance scaling. It might not be ideal, but it's a fact of life for the foreseeable future.
 
Except you get nearly twice as many frames so the game can respond quicker as well.

While you may get 2x the frames, you aren't getting 2x the response rate. Its really not that much better than just displaying the same image over 2 separate refreshes. The reality is that AFR is primarily a hack to win benchmarks and not a way to get a better end user experience.
 
While you may get 2x the frames, you aren't getting 2x the response rate. Its really not that much better than just displaying the same image over 2 separate refreshes. The reality is that AFR is primarily a hack to win benchmarks and not a way to get a better end user experience.

Well, we'll have to wait until *anyone* can get a better method for multi gpu scaling out there.
 
While you may get 2x the frames, you aren't getting 2x the response rate. Its really not that much better than just displaying the same image over 2 separate refreshes. The reality is that AFR is primarily a hack to win benchmarks and not a way to get a better end user experience.

2x response rate is possible, though I don't know if game engines do that. Latency is higher, but that's the tradeoff for better graphics quality. (Kind of similar to the tradeoff with vsync.)
 
Well, we'll have to wait until *anyone* can get a better method for multi gpu scaling out there.

Thats relatively easy, just need to allow the programmers access to the resources directly and incentive them to code to it.

A number of platform have supported multiple graphics chips and have been used very well (Saturn is the obvious poster child).

Its just the multi-gpu PC only platform is a tiny market, so even the IHVs haven't bothered to open it up yet to developers.

Deano
 
11.1 is to be expected - though I haven't a clue about the changes.

32nm this year seems unlikely, and it is SOI

http://www.brightsideofnews.com/new...dries-absorbs-chartered2c-the-race-is-on.aspx

Though, having said that, 32nm CPUs are to be launched next year and CPUs take ~twice as long from tape-out to shelf as GPUs, it seems. And there is some justification in expecting AMD to test 32nm SOI ahead of Llano with a discrete GPU of some kind.

For some reason GF is very coy about 32nm on its website. It's not shown as a "product".

Jawed
 
2x response rate is possible, though I don't know if game engines do that. Latency is higher, but that's the tradeoff for better graphics quality. (Kind of similar to the tradeoff with vsync.)

no it isn't possible by the nature of the technology. AFR does nothing about response rate. It in fact will always do nothing about response rate. Its the nature of the technology in that it is generating the secondary frame before the first frame has been displayed. And no latency is not the trade off for better graphics quality, certainly when you are getting no better quality.
 
no it isn't possible by the nature of the technology. AFR does nothing about response rate. It in fact will always do nothing about response rate. Its the nature of the technology in that it is generating the secondary frame before the first frame has been displayed. And no latency is not the trade off for better graphics quality, certainly when you are getting no better quality.
Even without multi-GPU, there is still more than 1 frame queued to the HW at a time, unless you are completely CPU-bound. In fact, I think Direct3D allows for 3 frames to be queued to the HW at once.
 
no it isn't possible by the nature of the technology. AFR does nothing about response rate. It in fact will always do nothing about response rate. Its the nature of the technology in that it is generating the secondary frame before the first frame has been displayed.

It begins to render a second frame before the first has been displayed, but after the first has been started. Like with triple buffering, the response rate depends on frame rate but there is a double latency from the beginning of render to display.

And no latency is not the trade off for better graphics quality, certainly when you are getting no better quality.

If you only used one of the graphics cards, you'd have to tune down quality to get the same frame rate. That's the trade off. (Sorry for stating the obvious.)
 
11.1 is to be expected - though I haven't a clue about the changes.

32nm this year seems unlikely, and it is SOI

http://www.brightsideofnews.com/new...dries-absorbs-chartered2c-the-race-is-on.aspx

Though, having said that, 32nm CPUs are to be launched next year and CPUs take ~twice as long from tape-out to shelf as GPUs, it seems. And there is some justification in expecting AMD to test 32nm SOI ahead of Llano with a discrete GPU of some kind.

For some reason GF is very coy about 32nm on its website. It's not shown as a "product".

Jawed

I'm not sure I'd consider that to be a particularly reliable source of information.

I can see reasons to tape out a GPU before you try and integrate with the CPU (i.e. Llano), but there's no good reason to use SOI for commercial GPUs shipping in high volume. SOI's more expensive than bulk, and isn't really a good fit with low cost or low power.

Moreover, Llano has already taped out...so unless this mythical SOI GPU taped out a while back...it isn't really going to be all that helpful in familiarizing the guys at ATI with the 'benefits' of SOI. The whole point is to start working with SOI ahead of time, so they are prepared. In order for that to really happen, they would have needed to tape out such a GPU a while back (say 6 months).

Of course, if AMD did have a 32nm product taped out 6 months ago...you think it might get to market. While SOI does add cost, that pales compared to the benefits of moving to HKMG and 32nm.

Bottom line: AMD could do a GPU on SOI, but it doesn't sound very plausible.

David
 
11.1 is to be expected - though I haven't a clue about the changes.

32nm this year seems unlikely, and it is SOI

http://www.brightsideofnews.com/new...dries-absorbs-chartered2c-the-race-is-on.aspx

Though, having said that, 32nm CPUs are to be launched next year and CPUs take ~twice as long from tape-out to shelf as GPUs, it seems. And there is some justification in expecting AMD to test 32nm SOI ahead of Llano with a discrete GPU of some kind.

For some reason GF is very coy about 32nm on its website. It's not shown as a "product".

Normally, I would say avoid BS News like the plague, but John Oram is a good guy.

That said, 32 bulk has been off the GF roadies for 6 months or more, it was off when I met with them at IDF, and likely before too. 32 SOI should be out in Q4 of this year.

For 28, there are two processes, 28LP and 28G (Graphics?), both HKMG. The wafer pictured here:
http://www.semiaccurate.com/2010/01/09/global-foundries-28nm-wafer-spotted/
is a 28LP with test structures on it (yes, I am 100% sure of that being test structures, take BS New's version at your own risk). You should see 28LP products this year.

28G (sometimes called HP or other things depending on who you talk to) is accepting customer designs in Q3 or so, but 28LP was pulled in, so it wouldn't surprise me to see 28G pulled in too. If GF takes 28G tapeouts on July 1, you could have big chip, IE GPUs out in Q4, but I wouldn't hold my breath for that, likely in Q1/11.

TSMC is promising 28 + HKMG suitable for graphics (I forget their process nomenclature) this year. They also changed from a gate first to gate last architecture when they pulled that roadmap in, and I have _ZERO_ confidence that they will be able to make anything at economically viable yields for at least 6 months after the promised date. Remember, their 40nm was an October 2008 launch (Altera in October, NV in November, ATI in December), and a year later, we are just getting to the point where they are stabbing at buttons praying that it fixes something.

So, theoretically speaking, TSMC HKMG 28nm graphics chips in Q4/10, GF HKMG 28nm graphics chips in Q1. Who is fabbing what where has been decided as well, and so far, I haven't seen one right guess online yet.

-Charlie
 
no it isn't possible by the nature of the technology. AFR does nothing about response rate. It in fact will always do nothing about response rate. Its the nature of the technology in that it is generating the secondary frame before the first frame has been displayed. And no latency is not the trade off for better graphics quality, certainly when you are getting no better quality.

At what frame rate does latency cease to be apparent to the viewer/player? Is 1/30th of a second per GPU enough? 1/60th?

-Charlie
 
Cease to be apparent or provide negligible benefits?

Even a casual gamer can notice a 10ms difference in input latency. More serious gamers can probably reap tangible benefits up to ~120 FPS, and I imagine "pro" gamers would see better results up to ~240 FPS. Of course, currently most people are going to be limited by their LCD monitor's refresh rate of 60Hz anyway.
 
If you only used one of the graphics cards, you'd have to tune down quality to get the same frame rate. That's the trade off. (Sorry for stating the obvious.)

The proper solution is to have the cards contribute separate samples to the multisampled image. You are effectively getting the same response rate and quality with AFR as without. So for things like increased detail settings for the image rendered, if you can do on a single card, two cards in AFR isn't going to improve things.
 
Back
Top