We are planning to release a new application in few months.

Main differences:
10% faster on Fermi.
it should support parallel gpu runs later on
it drops support to compute capability 1.1 and 1.2 (so it supports from 1.3 inclusive)

gdf

We are planning to release a new application in few months.

Main differences:
10% faster on Fermi.
it should support parallel gpu runs later on
it drops support to compute capability 1.1 and 1.2 (so it supports from 1.3 inclusive)

gdf

Is this going to be the cuda 4 app that was mentioned some time back? Or will you be supporting cuda 3.1 still?

---

BOINC blog

Yes. The new app will be cuda4.
I would like to keep a cuda3.1, but we have to see if it is the old app or the new one.

gdf

Yes. The new app will be cuda4.
I would like to keep a cuda3.1, but we have to see if it is the old app or the new one.

gdf

Thats interesting because the guys that do the Seti optimized app for the GPU's have stopped development on a cuda 4 app due to bugs with cuda 4. They are continuing to use cuda 3.2

I think you would be reasonably safe to move up to cuda 3.2 as most people will already have updated their drivers or will be able to once the new app is available. Einstein have a minimum of cuda 3.2 required for their (only) GPU app.

we are probably coming out when cuda4.1 is out.

gianni.

Thats interesting because the guys that do the Seti optimized app for the GPU's have stopped development on a cuda 4 app due to bugs with cuda 4. They are continuing to use cuda 3.2

That's not strictly true. You'll only see 3.2 builds released for public use now, and for the forseeable future, but testing and development is continuing behind the scenes - that's where [trac]changeset:24046[/trac] came from.

It appears that Cuda 4, especially on the WDDM platforms, requires significant changes in kernel synchronisation methods to bypass the increased CPU usage. Learning how to do that takes time for an unsupported volunteer developer, especially one focussed on optimising the application.

That's not strictly true. You'll only see 3.2 builds released for public use now, and for the forseeable future, but testing and development is continuing behind the scenes - that's where [trac]changeset:24046[/trac] came from.

It appears that Cuda 4, especially on the WDDM platforms, requires significant changes in kernel synchronisation methods to bypass the increased CPU usage. Learning how to do that takes time for an unsupported volunteer developer, especially one focussed on optimising the application.

This is what Jason said (on Lunatics):

Cuda 4.0 appears to have several performance & stability issues that likely only effect us, toward experimental optimisation etc. nVidia's going to get a boatload of questions & reports from information gathered there.

Now I took that to mean it has bugs. Perhaps the term "design features" is a better and more accurate description? Either way cuda 3.2 may offer a less painful way forward for GPUgrid.

This is what Jason said (on Lunatics):

Cuda 4.0 appears to have several performance & stability issues that likely only effect us, toward experimental optimisation etc. nVidia's going to get a boatload of questions & reports from information gathered there.

Now I took that to mean it has bugs. Perhaps the term "design features" is a better and more accurate description? Either way cuda 3.2 may offer a less painful way forward for GPUgrid.

Yes, that was the point they'd reached at the beginning of August, which is when that quote dates from. Although the particular experimental line (x40) that your question related to drew a blank, that doesn't mean that all forward progress has been abandoned. Yes, staying in the past is a "less painful" development route, but it isn't necessarily the best.

The last I heard (today), they were exploring http://www.idav.ucdavis.edu/func/return_pdf?pub_id=1039

Cuda 4.0 appears to have several performance & stability issues that likely only effect us

If I were a non-SETI developer that wouldn't scare me too much ;)

MrS

---

Scanning for our furry friends since Jan 2002

Can I ask whether the new application will incorporate the revised threadsafe BOINC API library, to avoid the downclocking issue with CUDA 4 drivers?

Previous reference: message 21334.

Probably. We have to do it a bit differently, but yes.

gdf

New acemd application in fall 2011, with the first month past, can we expect
the CUDA 4.0(/4.1?) application, in the next 2 month, or should this be Alpha--,
and Bêta-tested, before it's launched?

I noticed, running CUDA 4.0, already, isn't this driver dependent?

---

Knight Who Says Ni N!

The present applications are based on CUDA 3.1. So long as the driver used is CUDA 3.1 capable you can run the present tasks.

If/when a new app is developed using CUDA 4.0/4.1 developer tools, these will require the use of CUDA capable 4.0/4.1 drivers and will be subject to in-house Alpha testing, Beta testing (opt-in only), and perhaps some after-general-release tuning (should problems arise).

Some tasks have been recently released to finish off research, so I would speculate that these will be allowed to finish before going to a new CUDA app. Other than that it's usually down to availability, time and dependent on co-ordination of other changes (of which some are planned and being implemented).
Basically when they are ready.

Skgiven, that reads a lot like DNF: Coming "when it is done" from 3drealms.

We will probably postpone this new application in 2012 to focus on upgrading the server and the new AMD alpha application.

gdf