Gravitational Wave S6 Directed Search (CasA) - Instruction 'ld' requires SM 1.3 or higher, or map_f64_to_f32 directive

:) Did I mention I'm a tester? I push the "control switches" pretty hard, with this setup. Maybe there's something useful in those xml files, for either you, or for someone else. And, although not perfect, those settings really do help me to keep my system loaded exactly how I want.

Heck, just over the past couple weeks, I found a handful of more bugs. Basically, GPUGrid ran out of work, so I had to comment out the config that blocked Einstein/SETI/Albert/SETIBETA from the 2 beefy GPUs. But I only wanted to get a task from those projects when the beefy GPU couldn't get from any other project. So naturally I set the resource shares from 1 (where they could get multiple tasks in a single RPC call) to 0 (so they'd only get a task as a last resort). But I have another PC that can ONLY do those 4 projects on its GPU, and I wanted it to have resource share 1. So I used BAM to assign host-specific resource shares of 0 to my main PC for those 4 projects... except BOINC didn't respect it. That was a BOINC bug, and is fixed in 7.3.15.

But then my main PC started getting MilkyWay@Home (MW) GPU tasks, and I didn't want that. But I did want it to get other MW tasks, including the multi-threaded MT tasks. But I didn't want to just turn off those GPU tasks via project properties, because maybe some other PC I own might only be able to do MW for its GPU. And I'm not going to start using venues, either, ever.

So, back at BAM!, I set up a host-specific resource block, to block MW NVIDIA on my main PC. The client took it, but... curiously, back on BAM!, if I hit "attach all PCs to this project now" for MW, the setting got unset. That was a BAM! bug, that I think might be resolved, or is in the process of being resolved.

In fact, BAM! was using the old deprecated method of setting AMS resource blocks, and I think Willy and David worked together to use the newer method. While it was fixed, though, I tested, and guess what. The client ignored it. Son of a ..... :) It turns out, I had hit on a 3rd bug, where the client was not properly processing AMS resource blocks that use the non-deprecated way of setting them. That too, is supposedly fixed, in an upcoming alpha client release. In the meantime, Willy rolled back to using the older method, and I now have an AMS resource block for MW NVIDIA.

So, that whole thing was quite an adventure. But I think it's worth it. It uncovered 3 bugs, and I'm able to set it exactly how I want it. Having 3 generations of GPUs may be a hassle, but it's definitely GREAT for a tester to test with.

And then you go and throw in an application that requires SM 1.3 or higher. Pfffft. What we are missing is a way for the client to say "But, I have no GPUs that can work on that, so don't give me that." Or, better yet, "I have these 3 GPUs, they are all different, each has this set of compute capability and features. Oh, and also, for your project, these particular applications are blocked from running on these particular GPUs. Please fetch me some work for these particular GPUs." Maybe someday. In the meantime, I'm erroring out those tasks, unless admins tell me to do different.

Kind regards,
Jacob Klein

Yes, but in addition to just "seeing the list of GPU types properly", the server also needs "the list of which applications are excluded from which GPU", as well as "the list of which GPUs actually need work".

To accomplish all of that, David wants to eventually treat GPUs as their own resources, instead of "NVIDIA as a resource". One day ....

Until then, cc_config.xml and app_config.xml, like crazy, for the win.