HD 3800 series folding?

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.

 

si

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.

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.

 

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 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.

 

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.

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.

 

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 about the matter

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.

 

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.

 

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.

 

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.