PCIe Performance Problem with HD5870

[thyrsted]

Hi all.

Found this thread:
http://forums.amd.com/forum/message...=130923&STARTPAGE=1&FTVAR_FORUMVIEWTMP=Linear

And it seemes somewhat unclear wether the problem is the Radeon, The Intel Chipset, or some combination thereof.

Was actually looking for somewhere to tip someone at anandtech.com , as i thought this might be complex enough to be worth diving into.
With no luck.

It's seemes AMD's reaction - or lack thereof - is equivalent to Seagates handling of their brick-problem, thus it would be nice with some more qualitative info.

Does anyone have any examples where GPU=>CPU performance matters ?

Sounds like gaming performance isn't affected, but what about eg. CAD performance,
( i know the *right* way is quadro or Firexxx, but when you wont pay the premium).

T

 

[faxon]

this is somewhat interesting. as it is, the radeon 5870 GPU is the fastest chip on which to run milkyway@home work units, and im running them now without any performance issues. im also using 2 p45 boards to do it with, however i have a friend with an x58 board and a 5870 as well, could you possibly post all the tools that are being used to bench these cards to expose this issue? as it is now, im not having any performance problems, and my 5870s are 5 times faster than a GTX480 for what im using them for. the work units im processing however are only a few KB in size, so once they're on the card they dont really need to go back and forth that much, per work unit the cpu is only loaded a few %, only for fractions of a second, so system bandwidth obviously isnt even a concern here. there are plenty of people using ATI GPUs on x58 as well and not having issues with these apps either. if there's a problem that's slowing down anything that significantly though, it's worth looking into more, especially on a site with a large user base of skilled users like anandtech.

 

[Voo]

Seems like the p55/x58 chipset and Ati cards (not only 5series, 4series has the same problems) don't play well together, no problems with Amd systems or the 775 platform (works as you'd think for my e8400 and 4870).

Sounds like gaming performance isn't affected, but what about eg. CAD performance,
( i know the *right* way is quadro or Firexxx, but when you wont pay the premium).

Ahm you do know what a budget CAD projects usually have? The few bucks for GPUs that are supported by their thousands of dollars software really isn't a problem there, but that's a killer for GPGPU projects for the consumer space.. If they don't fix that problem, Fermi really is the only viable solution.

 

[thyrsted]

....
Ahm you do know what a budget CAD projects usually have? The few bucks for GPUs that are supported by their thousands of dollars software really isn't a problem there, but that's a killer for GPGPU projects for the consumer space.. If they don't fix that problem, Fermi really is the only viable solution.

Yearh, but companies using CAD as a part of their work, is not always prepared to pay large amounts for a minor increas in performance.

T

 

[Voo]

Yearh, but companies using CAD as a part of their work, is not always prepared to pay large amounts for a minor increas in performance.

T

I'm not aware of any cheap CAD software, so if someone really pays 30k$ for one license of AutoCad or whatever, I don't think they would want to save 1k on the cheaper gaming GPU and go through all the hassle of having a not supported GPU whose drivers probably wreak havok in the system.. just sounds like a bad idea, it's not about the performance gain, but the support and the drivers.

Though maybe there are some cheap cad solutions out there for people where it isn't that important - dunno

 

[lopri]

There was an old issue, which by and large was fixed via BIOS and chipset revisions on X58. At this point, only performance 'penalty' you see is likely from that benchmark.

http://www.anandtech.com/show/2542/2

Does anyone have any examples where GPU=>CPU performance matters ?

I don't have an example and I don't expect to see many (if any). There is a reason why a GPU has its own chipset (memory controller) and memory. The less communication between CPU and GPU, the better. This is also why you don't see much impact of PCIe/HTT/QPI on GPU performance.

It's seemes AMD's reaction - or lack thereof - is equivalent to Seagates handling of their brick-problem, thus it would be nice with some more qualitative info.

 

[lopri]

Besides which,

 

[Voo]

Besides which,

Judging from your sig you're using an AMD and a 775 system, so that's not really the question here

And performance for GPU->CPU? Well everything you compute on the GPU has to be sent to the GDDR and to do anything afterwards (let it just be printing [if you don't want to use the GPU directly] or storing the results) you've got to send it back to the CPU, so if you can't compress the data and only have to send back some few values that's a real problem.

The only thing that saves them is that there aren't lots of GPGPU applications out there, but for anyone working on stuff like that, that's a real problem

 

[lopri]

Well, then maybe this thread should have been posted in Motherboards Forum. Not saying this to you, Voo, since you're not the original poster.

And performance for GPU->CPU? Well everything you compute on the GPU has to be sent to the GDDR and to do anything afterwards (let it just be printing [if you don't want to use the GPU directly] or storing the results) you've got to send it back to the CPU, so if you can't compress the data and only have to send back some few values that's a real problem.

The only thing that saves them is that there aren't lots of GPGPU applications out there, but for anyone working on stuff like that, that's a real problem

The scenario you're presenting may someday become reality (with Fusion, Many Cores, or whatnot - we don't know what the future holds for us), but it's not even remotely close to the way GPGPU is being done (which is at its infancy) today. For example,

http://www.bit-tech.net/hardware/buyers-guide/2010/05/07/pc-hardware-buyers-guide-may-2010/6
http://www.nvidia.com/object/tesla_build_your_own.html

Anything can be a problem if someone wants to make use of something that's not existent. But be that as it may, it's kind of disturbing how to leap into a imaginary conclusion ("real problem"), however removed from reality, before any facts are established. And if - a BIG if - it can be a problem, chances are it will be resolved before it becomes a problem.

P.S. Does anyone with X58 experience lower-than-expected GPGPU performance?

 

[Voo]

Well since it's a combined problem between GPU and MB, I don't think it's that badly placed - after all Nvidia GPUs work just fine with those MBs..

The scenario you're presenting may someday become reality (with Fusion, Many Cores, or whatnot - we don't know what the future holds for us), but it's not even remotely close to the way GPGPU is being done (which is at its infancy) today. For example,

http://www.bit-tech.net/hardware/buyers-guide/2010/05/07/pc-hardware-buyers-guide-may-2010/6
http://www.nvidia.com/object/tesla_build_your_own.html

Maybe I overlooked something, but where exactly in those links do they specify how e.g. F@H or another current applications internals work?
Haven't looked at the sourcecode (or even run the program for that), but I'd wager you send some proteins, compute the results and send those back?
Not sure how much data those results are (maybe it's only a small percentage, in that case no real problem), but if you take for example encoding, you've got to send the whole encoded data back to the CPU which obviously hampers performance.
I've only written some programs in CUDA (and was more interested in the HPC aspects of it..), but memory bandwidth is one constraint you really shouldn't overlook, after all it's the upper boundary for your performance gain

 

[lopri]

Voo, I think we can talk more about this in a different thread or PMs. I re-read my previous posts and I was unnecessarily aggressive throughout the thread, and hope you didn't take any offense.

But I am kind of suspicious of the newly registered OP's intention.

Hi all.

Found this thread:
http://forums.amd.com/forum/message...=130923&STARTPAGE=1&FTVAR_FORUMVIEWTMP=Linear

And it seemes somewhat unclear wether the problem is the Radeon, The Intel Chipset, or some combination thereof.

Was actually looking for somewhere to tip someone at anandtech.com , as i thought this might be complex enough to be worth diving into.
With no luck.

It's seemes AMD's reaction - or lack thereof - is equivalent to Seagates handling of their brick-problem, thus it would be nice with some more qualitative info.

Does anyone have any examples where GPU=>CPU performance matters ?

Sounds like gaming performance isn't affected, but what about eg. CAD performance,
( i know the *right* way is quadro or Firexxx, but when you wont pay the premium).

T

 

[Voo]

Voo, I think we can talk more about this in a different thread or PMs. I re-read my previous posts and I was unnecessarily aggressive throughout the thread, and hope you didn't take any offense.

But I am kind of suspicious of the newly registered OP's intention.

Ah no offense taken and yeah threads like this are a bit suspicious and the thing is..

Can this be a major problem for GPGPU applications? Depends on the application, but possibly. But what is the reason most people buy consumer GPUs? Gaming (I'm not aware of any consumer applications besides encoding and distributed computing that use GPUs..). Is it any problem there? Nope and since it's probably just some kind of handshake problem or other, it really shouldn't be too hard to fix, though that's not saying they shouldn't fix such a problem..

 

[thyrsted]

....

But I am kind of suspicious of the newly registered OP's intention.

Well..
My intention was/is to shed some light on wethere there is a problem - if any - when using Radeon5xxx for anything else than gaming.

Though i may be corrected once again, i'd like to emphasize that there are lots of people using eg. ACAD on graphic controllers wich are not Quadro/FirePro.

So now is the time to derail this thread by lecturing me that this is NOT the way to go, megabuckbudgets etc..

So, - this may be the wrong forum, the wrong problem or maybe even the wrong poster.

In any case , i apologize...


T