AMD: R8xx Speculation
- Thread starter Shtal
- Start date
Sure, with the subsequent driver update.
You know, it's not such a bad analogy... Overclocking would be akin to exceeding the redline & in effect, speed margining the engine. These days you'd have to circumvent the rev limiter, of course. But as for software just using the machine, well anyone can just use 1st gear or WOT all the time, but that wouldn't fit the normal distribution of usage patterns. I love analogies.
Have we considered the alu density differences between GPUs or GPU & CPUs & effects of alu bound workloads?
Well fine, but then lets have AMD releasing a guide with their SDK that states that you can't do X/Y/Z on their cards... oh and probably forfeit a lot of good faith with Microsoft since I'm pretty sure Furmark is valid DirectX code
Certainly documenting it is one "solution" to the issue, but they would rightfully lose a lot of developer faith for that. Why would I write code for a card like that when there are other cards that are guaranteed to keep working no matter what I throw at them?
Heh, does your owner's manual explicitly state to not drive exclusively in 1st gear or with your foot constantly planted on the accelerator? Documentation isn't always enough.
Look at it like "there's nothing for free in 3D" esp wrt perf/mm in their 4k series. They addressed their oversight via hardware monitoring for such corner cases in the 5k series.
I don't entirely disagree with your contention, though.
Look at it like "there's nothing for free in 3D" esp wrt perf/mm in their 4k series. They addressed their oversight via hardware monitoring for such corner cases in the 5k series.
I don't entirely disagree with your contention, though.
Uhh, In most places you're taught and tested on that before you're even allowed to drive. This analogy is getting ridiculous though... it's not helping understand anything about the real subject at hand.
If there is indeed hardware monitoring then fine, it satisfies the constraint that I shouldn't be able to write valid software that breaks it. My understanding was that this isn't the case though and instead they are relying on non-100%-robust application detection to catch these "corner cases".
Well isn't that dandy, everyone must be great drivers.... I can willfully drive like a ninny or be a dyno freak, putting my engine at greater risk of failure. Just like an undergrad passing a degree, but being a sloppy or malicious coder or writing "corner case" stress testing code...
That's the point. I don't know any games where workload distribution is anything like these utils. Does it matter? Maybe. But it's been addressed.
hoom
Veteran
That's probably not the full truth, since throttling based on texture/alu ratio alone doesn't make sense. You could have a perfect texture/alu ratio, but the shader clusters could mostly idle around.
The analogy doesn't apply at all... all you're proving is how inappropriate it is. Lets give it up already!
Ah cool, thanks for the link. Looks like Anand agrees completely with what I've been saying, but it appears that they have indeed solved this properly in the 5k series - sweet
Now if they would just stop calling these applications "power viruses" or other such nonsense and accept that they are legitimate - albeit rare - workloads that the card has to handle 
Now if they would just stop calling these applications "power viruses" or other such nonsense and accept that they are legitimate - albeit rare - workloads that the card has to handle
Dave will not be pleased
Silent_Buddha
Legend
Actually the analogy is quite perfect.
Furmark's only purpose is to allegedly test the performance boundaries of a graphics card. That is no more or less valid than driving a car around at redline to test the performance boundaries of a car.
In the car case you're guaranteed to ruin your car if you do this extensively. Similar to how (if there's no software/hardware checks in place) you could theoretically do the same using furmark.
The assumption is that people are smart enough not to run at redline constantly, and smart enough not to run furmark constantly.
As reality has proven however. There are in fact people not smart enough in both cases.
And just like there are real applications (0) that I can think of that has a car running at redline constantly, there are are real applications (0) that I can think of that has a program running furmark code constantly.
In fact, code like that is far more common for CPUs than GPUs as it's far easier to saturate a CPU. CPU's also have a history of this and thus safeguards were implemented over time.
GPUs so far have a history of 1. And somehow people find it odd that safeguards weren't put into place before there was anything to show a need for such a safeguard?
Once the discovery was made, it was only a matter of time before safeguards were put into place...
I'm going to assume that in this case Nvidia ran into the power virus problem during design and validation of one of their GPUs in the past or that there was some communication between the the writers for Furmark and Nvidia through devrel or somesuch. While ATI hadn't.
Either way an extreme corner case that has thus far not had even the slightest miniscule mirror in actual applications.
Regards,
SB
Every weekend, there are cases where engines are pushed to redline for 3-5, sometimes longer hours of such abuse. Its called autoracing and the engines are built to take that punishment for that given period of time and then a bit more. But even in autoracing, you still have engines blowing up on the race track because they couldn't take the beating of redline racing for that long.
Doesn't matter... define "real application"? Furmark is a "real application"; what if I like watching the pretty pictures that it generates? Why can't I use it as my screen save? What about the "real" volume renderer in another thread here that was overheating cards when run for too long? Oh I'm sure that's not "typical" either? I don't give a damn what AMD thinks is typical, I want to run whatever I want on the card and not be concerned about it breaking. I have no such concerns on any NVIDIA cards or any CPUs and thus if AMD is unwilling to make similar guarantees then their cards are patently behind the times in this respect.
That's fine - good even! After reading even a little about the tech in the 5k series, I'm completely happy about the solution. So let me reiterate that the only problem here is AMD downplaying it as anything less than hardware not working properly. It is *not* the application's fault, it was the hardware, and they fixed it. Great, lets move on now
Unclear - a proven stability problem like this casts doubt on the source of other stability problems in the past. But the point, again, is that they have fixed what was a problem with previous hardware, no matter how "rare" it was or what AMD thinks of the programs that reveal it.
Bingo.
I'd wager the validation for GPUs is a lot less rigorous than for CPUs, but that's perfectly fine since graphics cards (for now) are mainly aimed at displaying graphics. There's probably lots more errors that we probably don't get to know about. I doubt anyone would even notice if 1 in 10^8 pixels were totally mis-rasterized at > 60fps. A piece of software totally breaking the GPU is another issue though...
leoneazzurro
Regular
As far as I can remember, it's not a problem of the GPU itself, it's a problem of the reference card. So yes, the source of this problem lies still in AMD/ATI engineering, but it's different from saying that the GPU breaks.
Anyway, I would be careful to say that "other cards" have not such problems, as this other thread
http://forum.beyond3d.com/showpost.php?p=1354512&postcount=1756
seems to hint.
Anyway, I quote Raqia about the GPU (and GPU cards) validation being not really adequate in the last times (power viruses but also i.e the bump gate), probably the low time to market and costs involved are lowering someway the standards, or they were simply already low and we had luck in the past
(i.e. I remember buying an ATI 9800 128 Mbytes in the past, and it was KO in two weeks, killing my MB too, and also this was a not so rare accident those times, I remember also first batches of 8800 GT had also problems, especially with power dissipation, and so on)
Anyway, I would be careful to say that "other cards" have not such problems, as this other thread
http://forum.beyond3d.com/showpost.php?p=1354512&postcount=1756
seems to hint.
Anyway, I quote Raqia about the GPU (and GPU cards) validation being not really adequate in the last times (power viruses but also i.e the bump gate), probably the low time to market and costs involved are lowering someway the standards, or they were simply already low and we had luck in the past
(i.e. I remember buying an ATI 9800 128 Mbytes in the past, and it was KO in two weeks, killing my MB too, and also this was a not so rare accident those times, I remember also first batches of 8800 GT had also problems, especially with power dissipation, and so on)
The problem here has never been the existence of a hardware bug. The problem is/was AMD downplaying and even denying that it was anything other than a problem with the hardware. I doubt NVIDIA would respond to that bug (which appears to be more of a chipset thing BTW) with "oh, well... try not to run new 3D applications with those drivers installed... the cards weren't really made for that. Just play Quake 3 - we tested that a bit".
Anyways I'm done with this topic... AMD has actually solved the problem in the 5k series, which is admission enough of there being a real problem anyways. I love the 4k/5k series hardware but trashing ('power virus'? come on...) an application for breaking their hardware just struck me as abnormally unprofessional. Whatever... back to sweet DX11 courtesy of AMD
Last edited by a moderator:
Similar threads
