Heads up guys - tidy the place up a bit, we've got a professional in our midst


You're quite right to call me out on that one - the original (and probably still current) v6.08 Berkeley download supplies 2.0 DLLs

I've updated SkyDrive, getting the number right this time, and adding genuine 2.1 DLLs. I don't remember anybody testing anything between the original release, and 2.2 (which were certainly tested, and a big improvement) - we were too busy getting the darn thing to run at all, any which way. 2.1 look to be close in size to 2.2, so might have some improvements over 2.0 - but no idea how much memory they need to run, or what the improvement might be. Miep, care to give them a whirl?

In researching the above, I came across http://developer.nvidia.com/object/cuda_archive.html - version numbers with release dates, and link through to the matching toolkit and driver downloads. That's gone onto my favourites list for future reference.

This shambles was largely due to the original Cuda DLLs being only 'weakly versioned'.  Probably due to customer support situations growing, and in part from people swapping around DLLs arbitrarily prior to Cuda 3:  nVidia have moved to a 'strongly versioned' model from 3.0 onwards, include the version in the name, and applications built with one Cuda SDK are meant to use particular library versions.   That and some other growing pain issues seem to indicate that early in Cuda's development, the scale of the idea itself may have been underestimated.

As far as getting the memory requirements down in the applications goes, with Cuda 3.1 there's a few options I'm looking at to remove use of the hefty CUFFT library, and reduce the minimum footprint.  Will be some time before that can be realised in working form though, so this investigation is valuable toward many users.

Jason

Not the memory requirements, no - I think most of the testers who have chimed in are running 512MB or higher.

There are special problems with running the 3.0 or 3.1 DLLs with the older v6.08, v6.09 or V12 applications, because of the 'strong versioning' introduced with 3.0, as Jason mentioned. The apps expect DLLs called 'cudart.dll' and 'cufft.dll', but the fft.dll has to have access to 'cudart32_30_14.dll' or 'cudart32_31_9.dll'. You end up having to have three CUDA DLLs, not two, with the 'rt' file copied and renamed (and listed under both names in both sections of app_info.xml.

That's the point. The "easy" approach fails after 2.3 - we found that out the hard way when 3.0 came out. I can talk you through it, but too late for both of us tonight.

I don't think anyone really "knows" that 2.3 requires more VRAM than 2.2, 2.1 or 2.0: it's been asserted, but without evidence. If they run overnight, that'll be good news.

That ran like a treat. And the increase in speed with the higher dlls is remarkable.

Of the 3 tasks that ran O/N 1 has validated and 2 are waiting for wingman. (for reference: valid pending pending)
Is there anything in stderr to check which dlls were used?

Thanks, much obliged.

I thought there wasn't, since I couldn't see anything but you can always have 'tomatoes on your eyes' - I'm not awake enough to translate german proverbs.

I'll throw the 3.0 dll in there anyway, if only to check the memory uptake.

Hmm good point. I was going to say I tried V12 on 257.21, but now I'm not sure. Will have to check the logs. Edit: I didn't. Only 195.62 and 258.98 got tested with the variuos dll's (3.x still pending).

One thing after the other Jason... no need to pull out fenceposts for waving

Todays O/N run just got reserved for Jason's *hint* *hint* fencepost.

daytime and O/N run Wu runtimes are not very comparable on my system. daytime will see a number of restarts, depending on how much idle time arises, O/N can run uniterreupted.
Also cooling and resulting throttling are different at work and at home. (the office has A/C but the gap between notebook and table is smaller)

I can note down elapsed, cpu and AR on the diffrent builds, dlls and environments, if you want me to. (and any other easily accessible parameter)