AMD: Southern Islands (7*** series) Speculation/ Rumour Thread

[caveman-jim]

Dave Baumann
If I am right you are an AMD employee

He's just pretending, he's actually a deep mole in AMD for B3D! Sshhh!

and I have a few questions for you. Seeing the perception in the market that GTX 680 is superior than HD 7970 (though I believe the HD 7970 is better when looking at both cards OCed and across a wide range of games) I am keen to know how AMD is looking to combat this market perception ? I feel AMD hasn't been aggressive enough in marketing HD 7970 compared to Nvidia with GTX 680. AMD should have asked websites to look at the benchmarks when both cards are OC'd. Given the OC headroom on HD 7970 it would definitely have made an impact on the market's perception of HD 7970 wrt GTX 680.
Also there seems to be severe criticism on drivers for AMD HD 7900, especially in multi GPU situations ? Tri-Fire + Eyefinity does not work on the 12.3 WHQL drivers. Even with HD 7900 RC11 drivers there are subjective opinions raised here like better smoothness of gameplay in SLI when compared with Crossfire. There are lots of complaints also about the quality of drivers on forums .

http://www.hardocp.com/article/2012/04/25/geforce_gtx_680_3way_sli_radeon_7970_trifire_review/10

Is AMD taking these criticisms seriously and doing something to improve the user experience. Its very discouraging to see good silicon being held back by software. I hope AMD does improve the situation soon. I have always been a believer in good competition within the PC industry. And we need a strong AMD to keep Nvidia and Intel honest.

Not to put words in AMD's mouth, but my impression is that AMD are very much aware of these issues you describe, and are actively working on resolutions to them.

Right now, I think the driver team are almost wholly pre-occupied with APU support, for the upcoming Trinity mobile product launch (in the next 2-3 weeks, I think).

From what I can tell, AMD's execution is completely personnel limited - there's not enough of them go around. They need a massive investment in the software side of things - drivers, application optimization - to unlock the full potential of the designs they can deliver. IMHO, and I have been known to be wrong [the good people here will quickly tell me ]

 

[dkanter]

I found this information indicating why the 680 is so efficient.
Will the 7000 series use TMSC new HP Process that allows for their first-generation high-K metal gate (HKMG) technology and second generation SiGe or something similar?

I don't know if Tahiti and Kepler use exactly the same process. I would assume so, but it's possible that AMD isn't using strained silicon.

Most of that blog post was relatively boring and unexciting, although it was nice to see #s for TSMC 28nm. They didn't look all that impressive though...

DK

 

[Alexko]

I don't know if Tahiti and Kepler use exactly the same process. I would assume so, but it's possible that AMD isn't using strained silicon.

What makes you think that?

 

[dkanter]

What makes you think that?

I don't know whether they used strained silicon or not. It's never been mentioned.

I'd assume they are, but there's no reason to believe either way.

David

 

[Kaotik]

Dave Baumann
If I am right you are an AMD employee and I have a few questions for you. Seeing the perception in the market that GTX 680 is superior than HD 7970 (though I believe the HD 7970 is better when looking at both cards OCed and across a wide range of games) I am keen to know how AMD is looking to combat this market perception ? I feel AMD hasn't been aggressive enough in marketing HD 7970 compared to Nvidia with GTX 680. AMD should have asked websites to look at the benchmarks when both cards are OC'd. Given the OC headroom on HD 7970 it would definitely have made an impact on the market's perception of HD 7970 wrt GTX 680.
Also there seems to be severe criticism on drivers for AMD HD 7900, especially in multi GPU situations ? Tri-Fire + Eyefinity does not work on the 12.3 WHQL drivers. Even with HD 7900 RC11 drivers there are subjective opinions raised here like better smoothness of gameplay in SLI when compared with Crossfire. There are lots of complaints also about the quality of drivers on forums .

http://www.hardocp.com/article/2012/04/25/geforce_gtx_680_3way_sli_radeon_7970_trifire_review/10

Is AMD taking these criticisms seriously and doing something to improve the user experience. Its very discouraging to see good silicon being held back by software. I hope AMD does improve the situation soon. I have always been a believer in good competition within the PC industry. And we need a strong AMD to keep Nvidia and Intel honest.

SLI is probably smoother (reduced microstuttering), but it's less responsive (added input lag due method used to achieve reduced microstuttering)
Essentially, all SLI FPS-results since G80 at least are invalid due the method nVidia uses to reduce microstuttering.

 

[raghunathan]

He's just pretending, he's actually a deep mole in AMD for B3D! Sshhh!



Not to put words in AMD's mouth, but my impression is that AMD are very much aware of these issues you describe, and are actively working on resolutions to them.

Right now, I think the driver team are almost wholly pre-occupied with APU support, for the upcoming Trinity mobile product launch (in the next 2-3 weeks, I think).

From what I can tell, AMD's execution is completely personnel limited - there's not enough of them go around. They need a massive investment in the software side of things - drivers, application optimization - to unlock the full potential of the designs they can deliver. IMHO, and I have been known to be wrong [the good people here will quickly tell me ]

Yes AMD needs to add more resources to improve the quality of their drivers. Good silicon is nothing without good software. By the time Trinity releases it would have been 4+ months from HD 7970 launch. The VCE feature is yet to be enabled on HD 7000 series. Thats unacceptable.

 

[silent_guy]

Essentially, all SLI FPS-results since G80 at least are invalid due the method nVidia uses to reduce microstuttering.

Maybe you should elaborate this claim just little bit more?

 

[Kaotik]

Maybe you should elaborate this claim just little bit more?

Here you go
http://techreport.com/articles.x/21516/11

Now, take note of the implications here. Because the metering delay is presumably inserted between T_render and T_display, Fraps would miss it entirely. That means all of our SLI data on the preceding pages might not track with how frames are presented to the user. Rather than perceive an alternating series of long and short frame times, the user would see a more even flow of frames at an average latency between the two.

 

[Alexko]

I don't know whether they used strained silicon or not. It's never been mentioned.

I'd assume they are, but there's no reason to believe either way.

David

OK, thanks. Perhaps Dave is at liberty to comment on this.

 

[lanek]

Yes AMD needs to add more resources to improve the quality of their drivers. Good silicon is nothing without good software. By the time Trinity releases it would have been 4+ months from HD 7970 launch. The VCE feature is yet to be enabled on HD 7000 series. Thats unacceptable.

Maybe cause i know it under a different acronym, but what is VCE ?

edit:
( haa yeaaah, i was not think to this one, Video encoder .. )

 

[trinibwoy]

Here you go
http://techreport.com/articles.x/21516/11

Frame time graphs will be affected, not necessarily average fps. The delay is inserted after rendering so the tradeoff is less stuttering for more lag. You would think after a couple frames of forced delays the GPUs would be running in lock-step naturally though.

 

[Kaotik]

Frame time graphs will be affected, not necessarily average fps. The delay is inserted after rendering so the tradeoff is less stuttering for more lag. You would think after a couple frames of forced delays the GPUs would be running in lock-step naturally though.

If you don't want the input lag to grow pretty much every frame, you'll end up ditching frames instead of sending them to the monitor every now and then to balance how often you send frames to the monitor

 

[trinibwoy]

If you don't want the input lag to grow pretty much every frame, you'll end up ditching frames instead of sending them to the monitor every now and then to balance how often you send frames to the monitor

It's impossible to increase input lag every frame. There's a maximum number of frames the system (including game time) can render ahead (3 by default I think). Eventually it will even out.

 

[silent_guy]

If you don't want the input lag to grow pretty much every frame, you'll end up ditching frames instead of sending them to the monitor every now and then to balance how often you send frames to the monitor

Do you think they are ditching frame with vsync on? If not, explain me how that's different, then.
To me, it's conceptually the same, except that with on you're stuck with fixed maximum rates, while in the other you can vary it. Both cases don't have to ditch. They just have to selectively back pressure from the driver to the app.

 

[silent_guy]

Here you go
http://techreport.com/articles.x/21516/11

BTW, it really surprises me that you forgot this quote from the article:

Those frames that show up "early" are delayed slightly—in other words, the GPU doesn't flip to a new buffer immediately—in order to ensure a more even pace of frames presented for display.

No word about ditching frames, though. Not surprising: it'd be very easy to figure out with some selected tests and it would cause an uproar of epic proportions.

 

[ECH]

BTW, it really surprises me that you forgot this quote from the article:

No word about ditching frames, though. Not surprising: it'd be very easy to figure out with some selected tests and it would cause an uproar of epic proportions.

What would you suggest this would mean then? Will we see future tools from IHVs?

 

[Kaotik]

Do you think they are ditching frame with vsync on? If not, explain me how that's different, then.
To me, it's conceptually the same, except that with on you're stuck with fixed maximum rates, while in the other you can vary it. Both cases don't have to ditch. They just have to selectively back pressure from the driver to the app.

The delay is added after the frame is already rendered, so you render as many frames as you'd render without such system, while with v-sync to my understanding you actually don't render more than those x frames per second?

Let's say you're achieving 100 FPS on average, that means 10ms per frame. However some frames take a bit shorter, some notably longer to render, say from 5 to 25ms.
It will be quite a job to balance those 5 and 25ms frames without making your 100 frames last over 1 second, if you're not ditching any frame(s)

 

[trinibwoy]

The delay is added after the frame is already rendered, so you render as many frames as you'd render without such system, while with v-sync to my understanding you actually don't render more than those x frames per second?

Correct.

Let's say you're achieving 100 FPS on average, that means 10ms per frame. However some frames take a bit shorter, some notably longer to render, say from 5 to 25ms.
It will be quite a job to balance those 5 and 25ms frames without making your 100 frames last over 1 second, if you're not ditching any frame(s)

You're not talking about rendering time are you? I'll assume you're talking about what FRAPS sees because that variance in successive rendering times simply isn't plausible.

In your example frame 2 doesn't actually take 5ms, FRAPS just thinks it does because GPU2 was working on it in parallel. It probably took somewhere around 25ms too and your real framerate is nowhere near 100fps.

Stuttering isn't caused by variances in rendering times. It's caused by the GPUs being out of phase. Ideally frame 1 will be displayed when frame 2 is halfway done. Frame 2 will then be displayed when frame 3 is half done etc.

All nVidia is doing is forcing that to be the case. If avg fps is 100 and frame 101 arrives 3ms after frame 100 they will delay it for 7ms. Eventually the two GPUs should be in phase pumping out frames ~10ms after each other for a nice even distribution and still at 100fps.

The question is how quickly does the metering react to changes in avg frame rate and how many prior frames does it use to calculate that average.

 

[silent_guy]

The delay is added after the frame is already rendered, so you render as many frames as you'd render without such system, while with v-sync to my understanding you actually don't render more than those x frames per second?

Who says so? What if you'd simply add a command in your command buffer that says 'stall pipeline for 2ms'? To the backend, this would look exactly as if the frame took longer to render. And the driver would be back-pressured by it, just like it is for vsync on cases.

Let's say you're achieving 100 FPS on average, that means 10ms per frame. However some frames take a bit shorter, some notably longer to render, say from 5 to 25ms.
It will be quite a job to balance those 5 and 25ms frames without making your 100 frames last over 1 second, if you're not ditching any frame(s)

The problem with thinking in extremes is that it removes attention from cases that can be dealt with. If you have a variation form 5 to 25ms, you're not going to fix that by delaying a bit here and there, and a more fundamental approach will be needed. But selective delays can be used for less severe cases, say, adding up to 3 or 4ms. This should make things look smoother without a perceptible lag.

Things don't have to be perfect under all circumstance in order to be an improvement. Just think about adaptive vsync: doesn't solve everything, but Kyle seems to like it a lot.

 

[Davros]

It will be quite a job to balance those 5 and 25ms frames without making your 100 frames last over 1 second, if you're not ditching any frame(s)

I have no problem with that as long as framerate counters and benchmarks dont report non rendered frames.