LESS PPD WITH AMD Radeon HD 7950 THAN AMD Radeon HD 6870

[darkcrystal33]

?
PPD around 6400+
GPU 1: AMD Radeon HD 7950
OpenGL 4.2 (AMD Radeon HD 7900 Series with 240 ext.)
OpenCL 1.2, Tahiti compute units:28@905MHz

PPD around 7100+
GPU 1: AMD Radeon HD 6870
OpenGL 4.2 (AMD Radeon HD 6800 Series with 236 ext.)
OpenCL 1.2, Barts compute units:14@900MHz

Folding Performance with gpu is dependant from cpu?
Have you a plan to optimize Folding@home?

[Jesse_V]

How many WUs have you observed to come to this conclusion? Yes, ATI GPUs take a CPU to fold, but that's how their drivers work, not anything that F@h is doing.

By all accounts, F@h is extremely optimized.

[bollix47]

The higher the last two digits in the model number can be significant when looking at PPD. In this case the 6870 stock Engine Clock is faster than the one on the 7950.

I don't have AMD but have a GTX 480 which usually gets 3K ppd more than my GTX 560ti on the same project.

A newer GPU is not necessarily faster for folding than an older one. It depends on the actual models involved.

[darkcrystal33]

Hi, i just come back to Folding@home
http://fah-web.stanford.edu/cgi-bin/mai ... kcrystal33

i take this conclusion only on 1 task (HD 6870) vs 2 task (HD 7950) since i come back


(HD 6870)


(HD 7950)

[darkcrystal33]

The higher the last two digits in the model number can be significant. In this case the 6870 stock Engine Clock is faster than the one on the 7950.

ok, thx

But, 7950 is really more faster (like x2) on others projects or benchs...



(HD 7950)



(HD 6870)

I take the best screenshoot (higher fps) in less time
benched with GpuCapsViewer on opencl gpu

[7im]

Drawing pictures is not the same as calculating protein simulations.

[codysluder]

Drawing pictures is not the same as calculating protein simulations.

The 7950 has 112 Texture mapping units compared to only 56 in the 6870 which will speed up tho frame rates of thos images, but FAH doesn't use TMUs so they provide no benefit. On the other hand, the memory clock rate of the 6870 is 1375 and the 7950 is only 1250. Not a big difference, but it is something that FAH uses and it favors the HD6870.

[mdk777]

Wow,

Sorry darkcrytal33, the information given so far is far from correct or direct.

You are of course correct. The AMD 79XX series is significantly more powerful in every respect.

Using LuxMark v2.0 to test Open CL

AMD 6850 {Barts, GPU, 12, 775}open cl 1.2

yields a score of 526 on the default test.

AMD 7970 {Tahiti, GPU, 32,1050}open cl 1.2

yields a score of 1619

So, on a program that can utilize the GPU compute capability of the card, one sees a 3X increase in compute capability.
(in my case going from the 6850 to the 7970)

Consequently, the answer to your question is not in the Hz, or the number of compute units on the card.
Rather, the direct answer is that Folding does not currently utilize the compute capability of the card.
With the advent of a new architecture, (AMD GCN) the existing Folding client is grossly inefficient.
This will not be resolved until the Folding software is reconfigured.
This is not unique to AMD. The Folding software has yet to be optimized to run on NVidia's Kepler architecture.

The short and direct answer is that your observations are correct. The situation won't change until optimized cores are released.

[bollix47]

It might not be 3x if you used the models we're discussing.

[mdk777]

It might not be 3x if you used the models we're discussing.

So noted in my post:

(in my case going from the 6850 to the 7970)

I also supplied the working OC used on both cards.

The point is that discussing the hardware characteristics in response to a question of software is misdirection.

The software does not utilize the hardware. Full stop.
Other software does.

When and if Folding will be optimized for the newer GPU architectures from both AMD and NVidia is another discussion. However, the direct answer is that it doesn't currently.

[Evil Penguin]

Right now the problem is AMD's OpenCL compiler.
There are certain bugs that need to be fixed/worked around before a GCN optimized core can be released.
The 7xxx series SIMD based GCN hardware should fold much better than the previous VLIW architecture.
The software just needs to catch up.

[mdk777]

well, they (AMD) are looking to the future to eliminate both latency of CPU GPU communication; and the multiply layers of software.

HSA

http://hsafoundation.com/what-is-hetero ... cture-hsa/

whether the( AMD SDK, openCL drivers, openMM gromacs,and finally Folding cores) software ecosystem ever catches up to the hardware ecosystem in the meantime remains to be seen.

[mdk777]

Speaking of HSA,

Here is a introduction by our alumnus MIke Houston:

http://v.csdn.hudong.com/s/article.html?arcid=2809880

The discussion of face recognition is especially interesting....While the slideshow is not shown, he describes a 10x benefit for GPU compute transitioning to a Multiple benefit for using CPU compute in a single software algorithm.
The ability of HSA to make this make this transition on the fly should be a game changer for FOLDING.

Of course , eliminating the PCIE bus will depreciate my $500 GPU....but that is life.

[mmstick]

I find you guys hilarious. There aren't really any problems with AMD's OpenCL compilers, but there are problems with the implementation of the AMD apps in folding@home. All the OpenCL scientific research projects at BOINC, in particular POEM (eats extreme memory), MilkyWay (dual precision only), and the new Help Conquer Cancer (needs lots of work units, fast processor, and fast system memory) apps (7950s are raking in extreme computations on these projects, defeating NVIDIA every time. A typical GTX 580 requires well over 300 seconds per work unit, with a lot of people reporting needing 1,260 seconds for 560s, similar figures for POEM), all compute as intended across all models across the board, even more, since they are BOINC based, they don't need to implement something as silly as a GPU whitelist. The project simply has the BOINC client to ask whether your model supports the right standards, and if so OKs and sends you either the NVIDIA or AMD apps with a default configuration based on the project owners settings, usually one core is allotted to opencl GPU work units to prevent any instances of CPU and GPU work units thrashing at resources. The last two numbers in AMD cards have NOTHING to do with the performance between different models. On AMD it is the last 3 numbers you need to take into account as per the actual power of the card. HD 6850 is at best the level of HD 7770, graphics and computational-wise. There are many things to take into consideration as per the resources of a card, you can't simply look at a Hz rating between different architectures. HD 6850 was an old 256-bit card, with a higher latency memory. HD 7950 uses a 384-bit memory interface running at significantly higher frequencies and smaller timings. My 6850s on HCC roughly take 210 seconds to complete one work unit. Meanwhile, my 7950 only needs 30 seconds due to various architectural improvements, (plus a nice 50% overclock). One of the major selling points of the HD 7000 series is the further improved GPGPU capabilities of the graphics card compared to prior primitive versions. Various architectural changes have happened to increase OpenCL computational power as they transition to HSA, so on top of the 3X increase in FLOPS compared to 6850, a lot of projects will see much more than a 3X increase in speed as I do with the 7x increase in HCC. At POEM@Home however, the calculations are so intense that the only way of fully saturating the power of a HD 7950 is to run a quad channel 2400Mhz DDR3 system due to the massive memory bottleneck because of the nature of the calculations they employ for their protein optimized energy model, where data must be constantly flushed to and from GPU -> CPU -> RAM -> CPU - > GPU, and even a HD 6850 requires a decent quad channel system to utilize, so HSA would be of great help here.

[mdk777]

There aren't really any problems with AMD's OpenCL compilers

Well, I wouldn't go that far; there are always glitches when going from one architecture to another and porting constantly changing versions of open CL.

However, I agree that disparaging hardware for software failings is silly.

The problem is the very long lag in producing optimized cores. Over the years, new architectures are introduced into the market before FOLDING is able to optimize the previous.
OPEN mm is on version 4.1, but it utilizes AMD sdk 2.4.

AMD SDK 2.4 was released exactly a year ago and we still don't have any optimized cores released on it.

2.7 was released in 5/18/2012.
Last month they(AMD) launched CodeXL
http://developer.amd.com/tools/hc/CodeX ... fault.aspx

NVIDIA has launched updated CUDA for Keepler.

The software is constantly being updated by both vendors. One to over two years delay in getting that software used in a FOLDING core is a major bottleneck for the project.

It is what it is, explain the lack of resources, or the complexity and collaborative nature of the project, fine.

However, I don't see any reason to put up smoke screens blaming changes in bus size, or faulty drivers.