Driver, application and VRAM requirement?

[Richard Haselgrove]

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

V12nokill and 2.1 dll (are you sure they are 2.1 and not 2.0 Richard? They don't have a version number on the details tab.) boinc 6.10.58 nvidia driver 195.62

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.

[Miep]

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.

Bah, again nothing on the details page. how are you supposed to tell them apart, aprt from the datestamp?!  *mutter*

Professional? Nice joke. I only pay attention, and the stock dlls were refered to as 2.0 on the SETI boards. As I said nothing on the details tab to indicate version number.

So, dropped the new 2.1 in.  I see less maximum RAM usage on the new  258.96 driver, so I'll revisit the higher numbers.

EDIT: If we get verification from Chelski on SETI NC about his being a mobile GPU there might be justification for adding 2.0 dlls to the installer...

[Jason G]

Bah, again nothing on the details page. how are you supposed to tell them apart, aprt from the datestamp?!  *mutter*

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

[Miep]

Oh wow.
So, the 2.1 dll works (202M max, one more than 2.0) - and probably thanks to the new driver, so does the 2.2, with a memory max of 250MB. That's a memory usage of 230MB above baseline.
(max memiory usage by 2.0 dropped by 17 MB with 258.96 vs 195.62 driver)

I'll try higher ones, but with a margin of 6MB left, it's a very small chance they work - the 2.3 at least. Have the memory requirements of 3.0 and 3.1 been tested?

[Richard Haselgrove]

Oh wow.
So, the 2.1 dll works (202M max, one more than 2.0) - and probably thanks to the new driver, so does the 2.2, with a memory max of 250MB. That's a memory usage of 230MB above baseline.
(max memiory usage by 2.0 dropped by 17 MB with 258.96 vs 195.62 driver)

I'll try higher ones, but with a margin of 6MB left, it's a very small chance they work - the 2.3 at least. Have the memory requirements of 3.0 and 3.1 been tested?

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.

[Miep]

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.

Sorry, you lost me on that one. I was going to take the 'easy' approach and rename the files to cut off the version number instead of editing app_info.

For the record 2.3 dll runs and goes to 250MB as well - isn't that one supossed to use more RAM? Going to give it the full over night run and deal with the next generation tomorrow.

[Richard Haselgrove]

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.

[Miep]

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.

Well, can only report what I see on my system - and since the 2.2/2.3 only work since the newest driver (258.96) wouldn't know if memory uptake on older drivers is different. They certainly all require less memory to run than before. (well the 2.0/2.2 do)

[Miep]

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?

[Raistmer]

Is there anything in stderr to check which dlls were used?

I'm afraid not.
Since 2.3 there was not such big speed improvement so probably with 2.3 DLLs you reached peak GPU performance until V13/CUDA 3.1 app will be introduced to public.

[Miep]

Is there anything in stderr to check which dlls were used?

I'm afraid not.
Since 2.3 there was not such big speed improvement so probably with 2.3 DLLs you reached peak GPU performance until V13/CUDA 3.1 app will be introduced to public.

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.

[Jason G]

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?

I just realised you're running Vista (That'll teach me to look properly, and make proper connections  ).  The newer series of drivers are Microsoft's WDDM driver model based, which uses a paged scheme for memory management where each application sees its own full address range. That is opposed to XP drivers physical video memory model which was prone to fragmentation & shared the video memory as one block.   IMO with the new drivers under Vista you *should* have no low memory issues running any of the newest builds (Though experimental Cuda 3.0 & 3.1 builds still to be determined ...*hint* *hint*)

Jason

[Miep]

I just realised you're running Vista (That'll teach me to look properly, and make proper connections  ).  The newer series of drivers are Microsoft's WDDM driver model based, which uses a paged scheme for memory management where each application sees its own full address range. That is opposed to XP drivers physical video memory model which was prone to fragmentation & shared the video memory as one block.   IMO with the new drivers under Vista you *should* have no low memory issues running any of the newest builds (Though experimental Cuda 3.0 & 3.1 builds still to be determined ...*hint* *hint*)

Jason

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

[Raistmer]

If GPU memory paging occurs you should not only check is it works or not but elapsed/cpu times too.
GPU memory swap could be performance killer (or not ).

[Miep]

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)