HD 3800 series folding?

[Mize]

Sorry if this is common knowledge. Every google I do with the keywords gets a few billion hits since every page seems to have a signature or something with "folding" in it.

Can ATI's new cards fold? I'm building a new rig for the kids and would prefer to have a folding gpu in it.

Thanks

[Dave Baumann]

The current versions of Folding@Home do not support anything other than the X1000 series. There was a preview of a new client coming up and I would wait for more information on that to see what solutions are supported. ;)

[ShaidarHaran]

Addendum to the above: the current F@H GPU client only supports Radeon models X1800, and X1650 XT through X1950 XTX. IOW: graphics cards based on R520, RV560/RV570, R580/R580+. RV505/RV515, RV530/RV535 are not supported.

[Bouncing Zabaglione Bros.]

Sorry if this is common knowledge. Every google I do with the keywords gets a few billion hits since every page seems to have a signature or something with "folding" in it.

Can ATI's new cards fold? I'm building a new rig for the kids and would prefer to have a folding gpu in it.

Thanks

Looks like there's a new client coming soon (http://www.beyond3d.com/content/news/524). Read the link to the blog. Given the hints and the plugging of ATI, there's bound to be a RV670 client sooner rather than later.

[Mize]

:) good

[swaaye]

oooo PS3 here comes your competition!

[pjbliverpool]

oooo PS3 here comes your competition!

Doesn't the X19xx already outfold the PS3 by a healthy margin? Its the numbers of them thats the problem in terms of competing witht te PS3, the R6xx will suffer even more in that regard.

[ShaidarHaran]

Doesn't the X19xx already outfold the PS3 by a healthy margin? Its the numbers of them thats the problem in terms of competing witht te PS3, the R6xx will suffer even more in that regard.

Not exactly... While true the GPU clients are performing approximately twice the FLOPs of the average PS3 (per client), they work on an even smaller subset of simulations and are therefore not as useful in a broad sense, thus they are awarded fewer points (an X1900 XT-class card completes one 330-point WU every 12 hours). It's hard to say what the peak GFLOP rate of each client is, as we only have an average of all active clients as per the stat page (http://fah-web.stanford.edu/cgi-bin/main.py?qtype=osstats). It is possible (and indeed probable) that one of the two client types is running more hours per day on average than the other, and so a completely-accurate comparison of the two clients isn't really possible based on these stats.

[digitalwanderer]

Is there ever gonna be an R6xx client? :(

[ShaidarHaran]

Yes. Soon.

[fellix]

http://img206.imageshack.us/img206/10/bigslide81fk3.jpg

[ShaidarHaran]

Yay! Now if only ATi could make a competitive single-GPU part for the high-end, I'd be interested in owning an ATi card again. Also, Stanford needs to adjust the point bonus for the various projects. PS3 and GPU projects just don't earn enough points. GPU folding is pointless if you can run the CPU SMP client.

[Mize]

Yay! Now if only ATi could make a competitive single-GPU part for the high-end, I'd be interested in owning an ATi card again. Also, Stanford needs to adjust the point bonus for the various projects. PS3 and GPU projects just don't earn enough points. GPU folding is pointless if you can run the CPU SMP client.

Toss in half-way decent linux drivers and I'd be there...unfortunately AMD/ATI GPU drivers are the suckage for linux.

[ShaidarHaran]

Toss in half-way decent linux drivers and I'd be there...unfortunately AMD/ATI GPU drivers are the suckage for linux.

As of late? Every time they put out a Linux driver that's any improvement I hear about it, and I don't even keep up on Linux news. Seems to me I've heard of several improved Linux drivers from ATi over the last year or so. Then again, I haven't used them so what do I know?

[Davros]

not that i know anything about folding but shaidars quote "GPU folding is pointless if you can run the CPU SMP client."
suggests there are 2 clients cpu folding + gpu folding
cant you run both at once ?

[ShaidarHaran]

not that i know anything about folding but shaidars quote "GPU folding is pointless if you can run the CPU SMP client."
suggests there are 2 clients cpu folding + gpu folding
cant you run both at once ?

Yes. And those that have run them side-by-side tend to get more points out of just SMP folding than running both. The problem is that GPU folding uses an entire core of the CPU to get its job done, and that really takes away from SMP folding. Due to the current point structure GPU folding just isn't worth it unless you have a single-core CPU that is not of the Core family. P4s, AXPs, Semprons, and A64 owners with 2900s/38xxs may want to run GPU folding, but anyone with a better proc will get way more points per day out of SMP folding.

[Dave Baumann]

I don't think thats accurate. GPU foling outscores CPU folding, so if you have a dual core you'll get more out of running a single CPU and GPU folding.

However, the overhead was caused by the use of DX in the initial version; I don't know how the new core uses the CPU, however being based on CAL means it should have a completely different characteristics. Also, with the new core (currently) being a superset of the PS3's capabilities, hopefully it will score inline with PS3 Folding; the initial GPU core was scored down relatively because it was working on a smaller set of projects. Finally, HD 3800 does have a higher performance math engine than anything the old GPU client ran on.

[ShaidarHaran]

I don't think thats accurate. GPU foling outscores CPU folding, so if you have a dual core you'll get more out of running a single CPU and GPU folding.

Dave, I know you know far more about GPUs than I, but I think you should check your info WRT folding. GPU folding does not outscore SMP FAH. Example: I score approximately 2300 points per day running project 2653 SMP work units (typical SMP WU) worth 1700 points each. That's on a Core 2 Duo E8400 @ 3.87GHz. The current GPU folding client can only achieve approximately 700 PPD on the fastest card capable of folding (X19x0 XTX). Even overclocked Crossfire'd cards can't outscore a <$200 dual core processor.

However, the overhead was caused by the use of DX in the initial version; I don't know how the new core uses the CPU, however being based on CAL means it should have a completely different characteristics. Also, with the new core (currently) being a superset of the PS3's capabilities, hopefully it will score inline with PS3 Folding; the initial GPU core was scored down relatively because it was working on a smaller set of projects. Finally, HD 3800 does have a higher performance math engine than anything the old GPU client ran on.

I've heard about the recent science parity with the PS3 client and that's quite an achievement. Really goes to show how far GPUs have come in terms of programmability. Too bad Stanford rates the PS3 & GPU WUs so low point-wise. GPU WUs are worth 330 points, and PS3 WUs vary from 200-385. I also run PS3 FAH basically 24x7 (when I'm not playing a game or watching a B-r movie that is) and get approximately 900 points per day. Still pales in comparison to SMP folding.

I've long been a proponent of a point adjustment for both PS3 and GPU clients, but Stanford has yet to act. Hopefully they wise up, as the active user base for both these clients has not only peaked, but seems to even be in decline.

[Dave Baumann]

Thats a fairly large overclock you're running there. R580's at default 3D speeds can be scoring reasonably higher (http://gpu.fahinfo.org/index.php?allscores=true&new=false&project=all&sort=ppd) than 700 PPD as well. Sure, the scoring has evened out, but thats just 3 month old hardware vs 2 years old - the milage is going to vary singificantly if you've not got the latest CPU and its going to change again with the new client.

[ShaidarHaran]

Thats a fairly large overclock you're running there.

And yet it is negligible in the overall scheme of things. I still maintain ~1900 PPD without the overclock.

R580's at default 3D speeds can be scoring reasonably higher (http://gpu.fahinfo.org/index.php?allscores=true&new=false&project=all&sort=ppd) than 700 PPD as well.

Not by much. I see one submission equating to a PPD value even close to what my C2D achieves with SMP FAH, and that is no doubt in Crossfire. How much power is that consuming and what does it all cost? It is both more costly initially and from a TCO perspective to run GPU FAH than it is to run SMP FAH, at least with the currently-supported hardware. Also, the stock-clocked R580 solutions appear to be scoring 770-780 PPD, it is the o/c'd solutions scoring 800-940 PPD.

Sure, the scoring has evened out, but thats just 3 month old hardware vs 2 years old - the milage is going to vary singificantly if you've not got the latest CPU and its going to change again with the new client.

So who's fault is it that GPU FAH only supports said 2 year-old hardware? And again, my CPU cost me <$200 and consumes less power @ full load than any of the supported graphics cards, let alone two of them. Also, an original C2D is just as capable of running SMP FAH as my Penryn is, and can still provide better TCO and PPD than GPU FAH.

I'm not bashing GPU folding or GPGPU, I've run it on both my X1900 XTX (when it was first released) and again recently on my X1650 XT. If Stanford decides to adjust the point value upwards I would support them whole-heartedly.

[Dave Baumann]

So who's fault is it that GPU FAH only supports said 2 year-old hardware?
You understand that the current client runs on DirectX? From a technical standpoint there's little reason why the current client couldn't be supported on HD 2000/3000.

[ShaidarHaran]

You understand that the current client runs on DirectX?

si

From a technical standpoint there's little reason why the current client couldn't be supported on HD 2000/3000.

And yet it's not. I would think if it were truly simple to make work with R6xx hardware, it would've happened by now. Vijay Pande seems to imply driver issues in his blog (http://folding.typepad.com/).

Again, I'm not bashing GPU folding, I think it's a good thing. I wish it were more popular, supported more GPUs (perhaps G8x and G9x as wel), didn't carry such a CPU overhead, and produced more points. I think the popularity would increase greatly if the other items I mentioned were enacted.

[Dave Baumann]

And yet it's not. I would think if it were truly simple to make work with R6xx hardware, it would've happened by now. Vijay Pande seems to imply driver issues in his blog (http://folding.typepad.com/).

No, they have consiously made a change of direction not to code via DirectX any more, but instead they have completely re-coded the new client with Brook. With the addition of AMD's "CAL" (Compute Abstraction Layer) we can remove the necessity of the DX interaction at all, giving more access to the hardware and removing some overheads.

The primary reason a CPU core is knocked out of action with the current GPU client is because of polling that the CPU is doing with DX. While I don't yet know the overheads for the new client, it is likely to be greatly reduced - it seems the inference from the following recent FAQ (http://foldingforum.org/viewtopic.php?f=9&t=1459) indicates that with the new client may not knock out a CPU core:

Can I install both the CPU and GPU systray clients?
Yes, they should coexist (I haven't been able to test this yet), but you need one free CPU to handle the GPU client (for now).

[ShaidarHaran]

No, they have consiously made a change of direction not to code via DirectX any more, but instead they have completely re-coded the new client with Brook. With the addition of AMD's "CAL" (Compute Abstraction Layer) we can remove the necessity of the DX interaction at all, giving more access to the hardware and removing some overheads.

The primary reason a CPU core is knocked out of action with the current GPU client is because of polling that the CPU is doing with DX. While I don't yet know the overheads for the new client, it is likely to be greatly reduced - it seems the inference from the following recent FAQ (http://foldingforum.org/viewtopic.php?f=9&t=1459) indicates that with the new client may not knock out a CPU core:

I understand all that, Wavey. What I meant was - if it *was* so easy to get GPU FAH running on R6xx hardware, why didn't they do it with the existing DX-based client? Again, Vijay Pande mentions driver issues on his blog.

[Tim Murray]

And yet it's not. I would think if it were truly simple to make work with R6xx hardware, it would've happened by now. Vijay Pande seems to imply driver issues in his blog (http://folding.typepad.com/).
This is due entirely to different driver paths between R5x0 and R6x0. The problem with early GPGPU efforts was that they still went through D3D or OGL, and drivers for those are designed with performance and visible correctness, not numerical correctness, in mind. I believe there were comments that getting the driver path working took a very significant amount of time (plus, wasn't there a driver fork for a month or two while they merged the folding path into the main driver?). The entire motivation behind CUDA/CAL instead of higher-level languages like Brook that sit on top of existing shading languages (well, besides exposing features that aren't available to HLSL/GLSL, like scatter and shared memory on G8x/G9x) is that you remove the complexity of the driver from the equation.

No, they have consiously made a change of direction not to code via DirectX any more, but instead they have completely re-coded the new client with Brook. With the addition of AMD's "CAL" (Compute Abstraction Layer) we can remove the necessity of the DX interaction at all, giving more access to the hardware and removing some overheads.
Wasn't the original client in Brook as well? Of course, that went from Brook to HLSL instead of Brook to CAL to the R6x0 ISA, so yeah, there's no D3D anymore. This is a good thing from a lot of standpoints--correctness, stability, ease of development (no more "hmmm do I have a bug or does the driver have a bug" discussions), and even performance. If you look at the original BrookGPU paper, there is some discussion about the number of outputs from a single function in terms of how many rendering passes the shader takes--I am under the impression that CUDA doesn't touch the ROPs and instead goes straight from the SPs to memory, so I'm guessing that Brook+/CAL do something very similar.

Plus, polling should be far cheaper than in D3D, in addition to ease of porting.

[Dave Baumann]

I understand all that, Wavey. What I meant was - if it *was* so easy to get GPU FAH running on R6xx hardware, why didn't they do it with the existing DX-based client? Again, Vijay Pande mentions driver issues on his blog.
No, he's not mentioning driver issues - he's talking about QA with an entirely new set of software and different client capabilities. It would have been quite easy to port the current client to R600 (I believe we have had it running), it just that using this new mechanism brings many advantages - including better performance, lower overheads and fewer regression issues when new DX drivers are released.

[ShaidarHaran]

No, he's not mentioning driver issues - he's talking about QA with an entirely new set of software and different client capabilities. It would have been quite easy to port the current client to R600 (I believe we have had it running), it just that using this new mechanism brings many advantages - including better performance, lower overheads and fewer regression issues when new DX drivers are released.

I'm not arguing that the new client isn't worthwhile, quite the opposite. All I'm saying is why was there never a DX-based FAH client that supported R6xx?

I found some info on the folding forum (http://foldingforum.org/viewtopic.php?f=10&t=1172&sid=f3b63b96a915bb8111a5d5e475adcf7a) about the matter

2xxx and 3xxx development was progressing well and an pre-beta client was demoed. Unfortunately a serious bug was found during internal QA which prevented its release in late Q4 07.

I may have been wrong about drivers being the reason behind the lack of an R6xx-supporting GPU client, but it would be hard to deny "driver problems" in the beginning. I seem to recall three drivers that were compatible with the GPU client over the course of about a year, one of which had stability issues.

I know GPGPU isn't the highest priority for the driver team, and AMD is certainly ahead of NV in the folding department, so don't take this as a slight against anyone, I'm just stating facts.

[Dave Baumann]

I'm not arguing that the new client isn't worthwhile, quite the opposite. All I'm saying is why was there never a DX-based FAH client that supported R6xx?

Because the new client is more robust! Evidently they felt it was better to put the effort into getting this method up and running as there are many more advantages to it.

I found some info on the folding forum (http://foldingforum.org/viewtopic.php?f=10&t=1172&sid=f3b63b96a915bb8111a5d5e475adcf7a) about the matter
No, they are still talking about the new client there, not the older client. The new client has been in development for quite some time

[ShaidarHaran]

Because the new client is more robust! Evidently they felt it was better to put the effort into getting this method up and running as there are many more advantages to it.


No, they are still talking about the new client there, not the older client. The new client has been in development for quite some time

I know the reference is to the new client. You still haven't answered my question though. If it was such a simple matter to get the old client to work with R6xx hardware, why didn't it happen? Obviously there have been issues and delays with the new client. If a "simple" fix could be made to enable R6xx support which would allow Stanford to significantly increase the user base (one would have to assume), why wasn't it done? All signs point to it not being so simple, if you ask me.

Again, if it really was so simple, surely that wouldn't detract from the development of a new, more flexible and robust client. Simple fixes are usually one-man jobs that take only a few man-hours to achieve.

[Dave Baumann]

You still haven't answered my question though.

I did. But I'll do it again.

The new client is evidently the preferred route. Instead of increasing the support under the old client its better to clean cut and go with the new client. Supporting R6xx under the old client could have been done fairly easily, but development was put into the entirely different new client that brings many more advantages, but also means initially much more development and testing work to make sure the results are correct.

I don't know what the Pande group will do with the old (R5xx) client once they have a reasonable number of users on the new, but personally I don't expect indefinate support of it.

[ShaidarHaran]

That makes more sense. Thanks Dave. I didn't think about the ongoing support aspect of development, just the initial cost of modifying the codebase.