AMD: R8xx Speculation

[Arun]

Gosh! Those are big numbers: 40nm will go from 4% to 10% of total in Q4, and the margin impact of that chamber matching issue will go from 1.5% to 2% despite forecasting it to be fixed sometime in the fourth quarter. I'm genuinely amazed that despite significantly greater issues than on 65nm/90nm, their ramp has been mind-blowingly *more* aggressive. They expect 20% by the end of 2010, but at this rate I wouldn't be surprised if they surpassed that again. Mind you it'd be even more impressive if they didn't have all these issues in the first place...

I wonder how much this is affecting the supply of R8xx, and whether it happened early enough to perhaps be the cause of their current supply constraint. When you order X wafers that you expect to become Y chips and you get many less than that, it's not really your fault (at least it's TSMC that takes the hit margin-wise). Obviously it should affect Fermi too but NVIDIA nearly certainly will not have enough supply anyway so I don't think that's much of an excuse in their case

 

[Psycho]

The 4870 doesn't have any hardware to regulate power consumption by rogue power-virus programs/code.

It think it's pretty clear that my 5770 is not throttling, considering the scaling. And especially on the low 4870 speed it is not. Even in furmark and overclocked the cooler can keep it around 55 degrees btw.

 

[CarstenS]

Not throttling because of higher temperatures or even not throttling in the conventional sense, right. But there's been a driver throttle in the Catalysts for over a year now (IIRC), which prevents RV770 and up from showing their true potential.

 

[Jaaanosik]

The 5xxx series. Better cooling means less power consumption indeed.
...

Can you prove it? How would you go about that?
The article was taken down. I guess they are double checking if what they claim is valid.

 

[mczak]

Can you prove it? How would you go about that?

This is nothing new, it's because resistance changes with temperature. Some nice graphs can be found here, though it makes less of a difference there: http://ht4u.net/reviews/2009/leistungsaufnahme_graka/index9.php - or take some cooler review: http://ht4u.net/reviews/2009/amd_radeon_hd5770_meets_ac_l2_pro/index5.php

The article was taken down. I guess they are double checking if what they claim is valid.

Right, says could have been measurement error (that the chips behaved differently, in any case I'm sure that there will still be some difference depending on temperature).

 

[Iron Tiger]

Hehe, not only all characters out of fur, but all buildings, geometry, terrain, etc... Would certainly be a funny if impractical application.

Viva Piñata.

 

[Mendel]

I'm getting this kind of error trying to run the amd demos on vista:

http://img27.imageshack.us/img27/5530/capture2mg.jpg

Where would I find this event log?

(The Unigine Heaven benchmark runs just fine with tesselation and all that though)

edit: found the event log. Apparently the error comes because 'Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.4053"' is not found.

Any ideas?

edit2: Success! I uninstalled every visual c++ redistributable thing and then reinstalled this: http://www.microsoft.com/downloads/...0FF-B072-9112BAB119C2&displaylang=en#filelist

Now it all works.

 

[neliz]

I'm getting this kind of error trying to run the amd demos on vista:
Where would I find this event log?

RMB "My Computer"
Choose Manage
Select "Event Viewer"
Custom views
Applications and Services Log

Application Log was only in XP

 

[trinibwoy]

Not sure if this was answered before but does anyone know how the hull and domain shader invocations are handled by RV870? With a maximum batch size of 32 for each how are they getting efficiency out of 64 wide wavefronts? TIA...

 

[Jawed]

Not sure if this was answered before but does anyone know how the hull and domain shader invocations are handled by RV870? With a maximum batch size of 32 for each how are they getting efficiency out of 64 wide wavefronts? TIA...

I suspect this is no different from the problem of vertex invocations - lines have 2 vertices, triangles have 3, how do you pack vertices into hardware threads ... I presume the invocations will be packed, since 32 is merely the upper limit.

An invocation count of only 6, say, would be even worse for efficiency without any packing. I don't know what R800's doing, and it took a while to put together a decent theory of how bits of GS, with it's variable amplification, works in R600...

Jawed

 

[trinibwoy]

Makes sense, thanks. Still waiting on someone to do an in-depth analysis on tessellation in general and DX11 tessellation in particular. A simplified overview of the various HOS representations and detailed info on what each new stage does would be great (with lots of pictures too for the simple folk like me).

Oh where art thou B3D!?

 

[liolio]

Still no leak about the redwood and cedar?

 

[AlexV]

Oh where art thou B3D!?

Imma gonna let you finish...

 

[Grall]

Hehe, not only all characters out of fur, but all buildings, geometry, terrain, etc... Would certainly be a funny if impractical application.

It doesn't matter how impractical you think it would be, at no point should software be able to break hardware. I repeat: AT NO POINT.

ATI fucked up, plain and simple. Wether it's on purpose or simply by incompetence I leave for wiser men to determine, but they fucked up. They put voltage regulators on their reference design that are TOO WEAK. And there's no defense for that. NO DEFENSE.

They fucked up.

The situation isn't entirely analogous since Intel doesn't provide reference designs that basically all mobo makers follow, but suppose there's some unlikely stream of instructions that could make a i7 processor overload its voltage regulators and either crash the system, or burn out the hardware altogether. Would anyone seriously just overlook that since no useful program would ever execute those instructions in real life? I don't friggin' think so!

 

[neliz]

Would anyone seriously just overlook that since no useful program would ever execute those instructions in real life? I don't friggin' think so!

Lol, you're the kind of guy that microwaves his Cat and then sues the whoever made it because it's obviously broken.

 

[Bouncing Zabaglione Bros.]

The situation isn't entirely analogous since Intel doesn't provide reference designs that basically all mobo makers follow, but suppose there's some unlikely stream of instructions that could make a i7 processor overload its voltage regulators and either crash the system, or burn out the hardware altogether. Would anyone seriously just overlook that since no useful program would ever execute those instructions in real life? I don't friggin' think so!

IIRC, you can destroy the I7 memory controller by upping the DRAM voltage too far with many of the Windows tuning utilities, thus destroying a critical part of the processor and rendering it useless.

 

[Andrew Lauritzen]

It doesn't matter how impractical you think it would be, at no point should software be able to break hardware. I repeat: AT NO POINT.

Yeah I have to agree with this... you can call a given workload atypical all you want, but that's no excuse for it screwing up your hardware. If the Futuremark game coming out soon has similar workload characteristics, whose fault is it then? Still Futuremark? "They shouldn't have called that function?" Nonsense.

 

[Dave Baumann]

If the Futuremark game coming out soon has similar workload characteristics, whose fault is it then? Still Futuremark? "They shouldn't have called that function?" Nonsense.

There's ISV / IHV developer relations, there's Q/A cycles, theres early build testing, etc. that exist way before that, it would show up and action would be taken. However, the simple reason that this exists is because the workload does not represent anything else around because it is sustained, constant and across the entire pipeline. Given the number of cases this shows up in, would you pay more for the graphics board to run this application, even when circumventing driver detects?

This is nothing new - CPU's have been through this in the past and they now cope with these cases by clocking down or inserting spurious instructions into the pipeline to give force processing bubbles. GPU's are only just now beginning to see such large differentials between "normal" workloads and "lit up" workloads because of the increased capabilities of the pipeline and also the increasing number of power saving features that are being introduced; we're just following CPU's in this regard.

 

[Bouncing Zabaglione Bros.]

This is nothing new - CPU's have been through this in the past and they now cope with these cases by clocking down or inserting spurious instructions into the pipeline to give force processing bubbles. GPU's are only just now beginning to see such large differentials between "normal" workloads and "lit up" workloads because of the increased capabilities of the pipeline and also the increasing number of power saving features that are being introduced; we're just following CPU's in this regard.

I dunno about that. Look at IntelBurnTest, which is a popular stability testing tool that wraps up Intel's Linpack into a user-friendly package. It stresses the CPU to the max and is designed to light up as much of the chip and RAM as possible. It's used by Intel for stress testing, and is the baseline they work to, ie they want stability at this maximum stress.

It's not downclocking or stalling, in fact there's nothing that heats up the CPU more. It even produces 10 degress more heat than maximum heat in Prime95.

This is considered to be the required capability of an Intel CPU, they don't claim it's an outside case and so isn't supported - they use the outside case as their limit, not some lesser measurement of performance.

Things like furmark or the wave simulator problems posted in another thread are simply utilizing more of the GPU chip than a lot of other apps, but it's there to be used. It's only going to get worse when you're pushing the like of CPGPU and Direct Compute and it will become increasingly unacceptable to simply say "we don't support workloads that are too high." You can't have your cake and eat it by claiming to have all these terra-whatsits of processing power only as long as no one wants to use it.

 

[Andrew Lauritzen]

There's ISV / IHV developer relations, there's Q/A cycles, theres early build testing, etc. that exist way before that, it would show up and action would be taken.

Not always - *I* shouldn't be able to write code that screws up my GPU either... that's not acceptable.

Given the number of cases this shows up in, would you pay more for the graphics board to run this application, even when circumventing driver detects?

Yes! The hardware should work as advertised, no matter what I throw at it. Obviously if it's rare it's less serious, but it doesn't excuse it just like it wasn't "okay" for the original Pentium to have the FDIV bug... and I'm sure you remember how angry people were with that, even though probably even fewer ever saw any problems in reality.

This is nothing new - CPU's have been through this in the past and they now cope with these cases by clocking down or inserting spurious instructions into the pipeline to give force processing bubbles.

There's a difference between things like "turbo mode" which detect thermal conditions and modify clock rates and such on the fly and an application being able to bring down the machine - which should never be possible. The issue here is if there is *any* way *ever* to make it fail, then it's broken, no matter how often you expect to see that case. I don't recall any (working) CPUs that would fail in the hardware for some workload, but please correct me if I'm wrong.

GPU's are only just now beginning to see such large differentials between "normal" workloads and "lit up" workloads because of the increased capabilities of the pipeline and also the increasing number of power saving features that are being introduced; we're just following CPU's in this regard.

No one is complaining about doing cool power savings and clock rate modification to keep the chip running at peak efficiency. The problem is you can't have the chip optimized for the 99% case, and fail catastrophically in the 1%. If you can 100% perfectly detect that 1% and down-clock or whatever you need to do to make it not die then that's completely fine, but I reiterate: the software should never be able to bring down the hardware.