I would like this thread to get back on track, towards the OpenCL error, if possible. Thank you.

I would like this thread to get back on track, towards the OpenCL error, if possible. Thank you.

Excuse me for posting in YOUR thread. Won't happen again.

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

I don't understand the attitude. I was being as friendly as I could muster. Sorry to have offended you. I encourage you to reply to threads, including mine, going forward. I'd like it to stay on topic though.

I did very specifically keep this hardware / driver / OS discussion separate from the sticky thread at the top. We'll have an additional data point on Tuesday, when my new card arrives.

Pretty sure we already determined early on in the thread that the issue was the nvidia drivers having borked openCL on Win10 with the SoG app. Either wait for nvidia to fix it, or change the app. What’s left to discuss?

Are you married to the SoG app? Tbar has posted an app that works properly with the new drivers several times (between this thread and the other) and it’s my impression that the sah app is pretty much the same performance as the SoG app. Is that wrong?

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

I'm sorry, but I don't fully trust what TBar posts. In the current Mac Beta thread (still no testing news actually posted at Beta, to say what the test is actually for), he says that the new App "... is named MBv8_8.22r4008_ati5-SoG_ssse3_x86_64-apple-darwin. That's the way it comes out of the compiler." r4008 is a Nebula commit by David on 28 February ("add comments, fix code formatting"). Raistmer did a couple of SETI science app commits for Petri at r3999/r4000 on 5/6 Feb, but I don't think theyre anything to do with Mac. So - proper release practice, please, and then I'll look.

Who’s talking about the Mac app? I think you’re confusing some of his other posts in regards to that.

But in the stickied thread on this issue, is this post:

At this point it's pretty clear the problem doesn't exist when using the Non-SoG version of the App. So, if you are using the Lunatics version of SoG it's as simple as changing the App over in the app_info.xml to the version here; http://boinc2.ssl.berkeley.edu/beta/download/setiathome_8.16_windows_intelx86__opencl_nvidia_sah.exe
Download the 8.16 App, place it in your setiathome.berkeley.edu folder, then change your app_info.xml to name the new App instead of the SoG version. Since Lunatics usually creates a 5+ page app_info.xml, it would probably be best to use find & replace ;-) I think both Apps uses the same libfftw3f-3-3-4_x86.dll, so, you probably don't need to change anything else.

You can see the setiathome_8.16_windows_intelx86__opencl_nvidia_sah.exe App working with Arecibo VHARs at beta, https://setiweb.ssl.berkeley.edu/beta/results.php?hostid=87127&offset=220

That’s the 8.16 r3486 app. That’s the one I’m referring to.

If you follow the links to the host, you’ll see the app version, driver version and OS being used. Looks like it’s working to me for the Arecibo VHARs.

Example: https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=34797831

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

Fair enough, but I think I was involved in the pre-release testing for that one. Better than nothing, of course, but significantly slower than SoG. I'm using SoG r3584, so it's older, too - possibly less precise (I've forgotten when we got the last validation bugs out - the final stages were speed tuning).

The instructions also need to mention changing the MultiBeam_Kernels_r3584.cl file to one which matches the build expectation of the main app.

But it's turned midnight while I was typing this, and I'm off to bed.

I'm sorry, but I don't fully trust what TBar posts. In the current Mac Beta thread (still no testing news actually posted at Beta, to say what the test is actually for), he says that the new App "... is named MBv8_8.22r4008_ati5-SoG_ssse3_x86_64-apple-darwin. That's the way it comes out of the compiler." r4008 is a Nebula commit by David on 28 February ("add comments, fix code formatting"). Raistmer did a couple of SETI science app commits for Petri at r3999/r4000 on 5/6 Feb, but I don't think theyre anything to do with Mac. So - proper release practice, please, and then I'll look.

Interesting, perhaps you should ask Eric why he placed the Apps on Beta since you don't 'fully' trust my posts. Before you do, ponder this line carefully, Anyone with MacOS 10.12 Sierra or higher.... Anyone knowing anything about MacOS, or even Linux, would be able to make a number of conclusions from that line. Also note 10.12 is Higher than 10.11, which was the last time Apple made a significant change to OpenCL. I could have used any version of sah_v7_opt I wished from the last couple of years, I chose the last one I had downloaded before I began getting this error, Trac Error... Eric can enlighten you to that as well...

Anyone wishing to use the Working Windows r3486 can find everything in Raistmer's post, https://cloud.mail.ru/public/A7yG/k8yoZrFvr Don't worry about the name, I suspect that's basically how it comes out of the Windows compiler with a couple minor changes. Or, you can brainstorm it for a while and try replacing the File name in the link, http://boinc2.ssl.berkeley.edu/beta/download/MultiBeam_Kernels_r3486.cl
BTW, while you're at it, ask Eric Who suggested placing the Non-SoG Windows App back on Beta....

Interesting. GTX 970 has dropped off the sales lists, of course. But there seems to be such a beast as a GTX 1660 SUPER (Asus dual fan) with fast GDDR6 memory, DVI output, and a Windows 7 driver (441.08 only) - and at a reasonable price for "new in". That ticks all my boxes (not ready to upgrade from DVI KVM to HDMI yet!). Worth a sleep on it and a re-check in the morning.

From the reviews i've seen the GTX 1660 Super sits between the GTX 1060 & the GTX 1660Ti for gaming; for compute workloads it's pretty much on par with (even slightly ahead of in some cases) the GTX 1660Ti.
It costs a bit more than the GTX 1660, quite a bit less than the GTX 1660Ti, so it's looking like the new performance v price king.

---

Grant
Darwin NT

NVIDIA released 441.12 drivers today.
I tested them, and they still have the "SETI OpenCL SoG VHAR" problems.
Maxwell: Tasks crash with error.
Pascal/Turing: Tasks run indefinitely with no load on the GPU.

We must continue to be patient.

New GTX 1660 Super arrived this morning, after a delivery failure yesterday.

06/11/2019 10:54:38 |  | CUDA: NVIDIA GPU 0: GeForce GTX 1660 SUPER (driver version 441.12, CUDA version 10.2, compute capability 7.5, 4096MB, 3034MB available, 5153 GFLOPS peak)

Pleased to confirm that with the Windows 7 version of that 441.12 driver, it does not suffer from this bug:

WU 3721505953

Note that this WU was a resend, because the middle task failed with a 436 driver under Windows 10 - so it's a valid test case. Meanwhile, the standard BLC13 tasks are purring along at well under five minutes a throw.

NVIDIA released 441.20 drivers today.
I tested them, and they still have the "SETI OpenCL SoG VHAR on Windows 10" problems:

Maxwell:
> Tasks crash with error.
>ERROR: OpenCL kernel/call 'clEnqueueMapBuffer(gpu_GPUState)' call failed (-36) in file ..\analyzeFuncs.cpp near line 1995.

Pascal/Turing:
> Tasks run indefinitely with no load on the GPU.

431.60 are the last drivers that work correctly for those specific SETI tasks on Windows 10.
NVIDIA is aware, and per NVIDIA, we must continue to be patient for a driver version that includes a fix.

So what happens when nvidia takes the position “this is the way we want our drivers to be now, fix your app instead” ?

I’m amazed that not a single person is willing to just change the app. According to the FLOP readings, the SAH app is quite close to the performance of the SoG app, only it doesn’t have this problem.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

If NVIDIA decides to go that route of "WontFix", then I will be informed, and will relay that info.
In the meantime, they are working on a determining a root cause with hopes to fix, and are requesting patience.

Actually Raistmer will have to go through his code there again to make sure that it's not his problem first before hitting M$ up for those undocumented changes that they make at times (otherwise why is it just Win10 having this problem and not any of the other OS's?).

Cheers.

We've got some positive results indicating that 442.19 has fixed this issue.
Tracking it here:
https://setiathome.berkeley.edu/forum_thread.php?id=84694&postid=2030685