Is this a possible way of cutting corners to getting something to work for ATI GPU's? http://www.fixstars.com/en/solutions/opencl/compiler.html

---

We are waiting for ATI to fix their compiler and libraries. There is no much we can do. Some new tests are in progress these days.

Looking at the progress we are moving, I would expect to be in a stable, production situation with a OPENCL ATI application for GPUGRID before the end of the year. Of course beta work will start several months before. Maybe even just after the summer. All depends on them.

If they do a good job, I would expect an ATI 5870 to be within a factor 2 slower or faster than a GTX480. I know that the two extremes are quite different, but remember that few months ago, an ATI 5850 was 10 times slower than a GTX275 with ACEMD...

gdf

Thank-you for the update. Good to read where developement is at and moving along...

M

We are waiting for ATI to fix their compiler and libraries.
gdf

From this post http://oscarbg.blogspot.com/2010/07/ati-stream-sdk-roadmap.html are you going to send some beta test in aug?

Hi,
I really don't want to bother anyone, but I don't understand the troubles, that araise in this project. So let me please ask one question:
Seti has working apps for cuda and cal
Milkiway has apps for cuda and cal
collaz conjectur has apps for cuda and cal
einstein has apps for cuda
and they all work with my old gtx260/ATI-GPU's, some of them with my 250-GPU.
I understand, that the 260-192 has (build-in)troubles, but all ATI-cards work without any problem in all related projects.
Are these apps producing wrong results?

I'm not so happy to cruch for the search for numbers (collatz) and I'm waiting for a more intresting project (that may help more people than a handful of math freaks), that use my gpu's. Doesn't it make sense to try to connect the programmers of these project, just to exchange experience? They should have the same problems and they seem to have a solution.
Well, I'm not in the process of developing these apps, so my thoughts may be completely wrong. If so, then please forget my question.

Regards,
Alexander

CAL is the old programming model. It is deprecated. If you have an old application it makes sense to use it still, for a new one, it's better to wait for OpenCL.


gdf

Hi,
I really don't want to bother anyone, but I don't understand the troubles, that araise in this project. So let me please ask one question:
Seti has working apps for cuda and cal
Milkiway has apps for cuda and cal
collaz conjectur has apps for cuda and cal
einstein has apps for cuda
and they all work with my old gtx260/ATI-GPU's, some of them with my 250-GPU.
I understand, that the 260-192 has (build-in)troubles, but all ATI-cards work without any problem in all related projects.
Are these apps producing wrong results?

I'm not so happy to cruch for the search for numbers (collatz) and I'm waiting for a more intresting project (that may help more people than a handful of math freaks), that use my gpu's. Doesn't it make sense to try to connect the programmers of these project, just to exchange experience? They should have the same problems and they seem to have a solution.
Well, I'm not in the process of developing these apps, so my thoughts may be completely wrong. If so, then please forget my question.

Regards,
Alexander

If there will ever be an ATi support for GPUGrid, will double precision be required for the card? In other words, will I be able to run GPUGrid on 5770s?

I dont think double precision is on the cards (it is not needed now), but that does not mean that a 5770 would not work. If ATI GPUs do eventually work here, that card should be a good one.

Hi,

We'll probably be in a position to start testing of an ATI application after SDK 2.2 is released in a month or so. It will require a 5800-series card initially.

MJH

@MJH: may I ask why? To keep things as simple as possible initially or is there any important technical difference for GPU-Grid between e.g. HD58x0 and HD57x0?

@Werkstatt: I'd put it this way: imagine some guy compiling a "hello world" program in C++. Now there's another guy who's trying to build the perfect operating system. He may also be using C++, but can not get it quite as bug free and stable within a finite development time.

It's not that the other projects would be trivial (*), but they're using different functions, libraries and API calls. Apart from the fact that they're using a different API these differences in the code alone would be enough so that you can not simply say "Just do the same stuff the others did and it should work". Well, it probably would work, but it wouldn't be doing any GPU-Grid science ;)

Are these apps producing wrong results?

That's not the point (and is probably not the case). For GPU-Grid the problem is that using the current SDK the app is not stable. And if I understand correctly the problems have been traced down to API calls (functionality provided by ATI), so it's up to them to fix it.

MrS

(*) the code of CC and MW is not very complex, but certainly not trivial either

---

Scanning for our furry friends since Jan 2002

may I ask why? To keep things as simple as possible initially or is there any important technical difference for GPU-Grid between e.g. HD58x0 and HD57x0?

The 58x0 is what we work with here. A 57x0 app may follow, probably, if all goes well and they prove to be fast enough. Lower 5xxx series cards will definitely be too slow to be useful. And the 4xxx is right out.

MJH

Hi,

thank's to your and GDF's efford to explain, whats going on.

[quote}
Well, it probably would work, but it wouldn't be doing any GPU-Grid science ;)
[/quote]
I really like these words! Yes of course, beside the results in the project itself there should be a progress in gpu-computing as well!

I am looking forward to the first apps for my 5830 and maybe also sometimes for my old GTX260 too ...

Regards,
Alexander

[quote]
And the 4xxx is right out.

MJH

Why? The 4850, 4870, 4890 & 4770 are generally faster than the 57xx and support DP to boot. The 57xx does not.

Why?

The design of the R700 processor used in the 4xxx series cards prevents the complete implementation of some features of OpenCL that are of critical importance for our application. (It's yesterday's technology, sorry!)

MJH

Why?

The design of the R700 processor used in the 4xxx series cards prevents the complete implementation of some features of OpenCL that are of critical importance for our application. (It's yesterday's technology, sorry!)

MJH

5xxx series has OpenCL 1.1 support. If you can get the 57xx series to work, at least you aren't going for DP :) .

GPU-Grid doesn't need DP and this is hopefully not going to change anytime soon. At least one important difference between the 4000 and 5000 series is flexibility in memory management, if I understood correctly.

MrS

---

Scanning for our furry friends since Jan 2002

i guess you could say that. local data share on rv770 was too restricted to meet opencl requirements.

http://support.amd.com/us/kbarticles/Pages/OpenCL11ATICat107UpdateDriver.aspx
Can someone confirm that Cat 10.7b with ATI Stream SDK 2.2 has support for OpenCL 1.1 for 4xxx series?

Does this mean that the new SDK is available and testing of the ATI-apps is going on?
I have 2992 ATI GFLOPS currently crunching mainly for milkyway and I would assign some of them to GPUGRID.

Regards,
Alexander

Perhaps the scientists will have another look at ATI cards in September or October, but they have a lot to do; optimize the GTX460, and forthcoming GTX475, try to get working apps for the GTS450, GTS445 and GTS440 (due out on the 12th), as well as the GF108 cards, also due out soon.

Last I heard they were perhaps about 50% of where they wanted to be WRT performance, but there were still bugs in the ATI code, that would require fixing before they could progress. If ATI have fixed their compiler and libraries then I would expect GPUGrid would be keen to restart work on an ATI application quite soon after the summer holidays.