Thanks for report.
Actually, I don't consider VLAR as something that shoulod be excluded for OpenCL app. It meant to be universal one.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Use search in this thread for solution vs driver restarts with 8.12

I would recommend to install r3500 or switch to beta for v8.17 testing.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Well, I've been running r3500 for a few days now, and so far, so good. Apart from the usual suspects (stock apple-darwin builds, intel_gpu builds, and one example of Petri's "special" code), only three inconclusives seem to form a class worth commenting on.

blc5_2bit_guppi_57451_65998_HIP117463_0013.15104.831.17.26.243.vlar
blc5_2bit_guppi_57451_65998_HIP117463_0013.29000.831.18.27.5.vlar
blc5_2bit_guppi_57451_66661_HIP117473_0015.14221.831.17.26.213.vlar

The common factor is that these are all late-onset overflows, where my SoG was matched against a stock CPU wingmate. Might one hazard a guess that differences in signal processing order are responsible for the very different signal counts reported?

SoG r3500 now available via a Beta4 installer too - refer to Open Beta test: SoG for NVidia, Lunatics v0.45 for details.

Grumble grumble - I updated the NVidia driver on my development machine to 350.12 so I could test SoG - first driver update in two years. Now SoG is running while I work, but I had a cuda42 memory-related temporary exit and black screens when I tried to run a forum advanced search here.

@ Raistmer,

BilBg has been proof-reading my Beta installer, and found that there are two different versions (*) of MultiBeam_Kernels_r3500.cl in circulation - the one supplied with MB8_win_x86_SSE2_OpenCL_ATi_r3500.exe (only) is newer and larger than the one supplied with ATi_HD5 and NV_SoG - the latter two are identical.

That's a no-no for the installer - it's not well-defined which version will be used if two different applications are installed at the same time. (It might also explain some of the wrong download size errors people were getting with stock v8.17 downloads at Beta). If you update a file, you must bump the version number too.

* re-confirmed here with fresh downloads from mail.ru this evening.

...A possible quick solution is to run the S@h advanced setup prog: Lunatics v0.45 beta3
(FYI, even though it is for advanced users/testers, no one has reported any bugs/issues with it since it was released in May)

Now installed on ONE of my desktops; the other isn't ready for this.

Intel Q9650 3.00 GHz
Nvidia GTX 560, 362.00 driver
64-bit Windows Vista SP2
BOINC 7.6.22
selected SSE4.1 and cuda42 options for MS, SSE3 for AP

One possible problem seen so far:
The above download site appears to offer TWO 32-bit and TWO 64-bit versions, with not enough of their names showing to tell if they have identical names. I tried to download both 64-bit +versions, but only one actually downloaded, so that's the one I installed, Size of the .exe file: 21,502,724 bytes

A file displayed after the installation looked like it might have been written assuming an AMD GPU instead of an Nvidia GPU, even though I told the installation to use option cuda42.

selected SSE4.1 and cuda42 options for MS, SSE3 for AP

And how this related to OpenCL 8.12 support thread?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

selected SSE4.1 and cuda42 options for MS, SSE3 for AP

And how this related to OpenCL 8.12 support thread?

You might edit OpenCL into the thread name, then?

selected SSE4.1 and cuda42 options for MS, SSE3 for AP

And how this related to OpenCL 8.12 support thread?

You might edit OpenCL into the thread name, then?

Do you see any other 8.12, especially any other GPU 8.12??

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

selected SSE4.1 and cuda42 options for MS, SSE3 for AP

And how this related to OpenCL 8.12 support thread?

You might edit OpenCL into the thread name, then?

Do you see any other 8.12, especially any other GPU 8.12??

Most casual readers wouldn't even know where to find the applications page, let alone read it. Why not be clear and explicit, and put all relevant information in one place? it's only an extra six letters.

Most casual readers wouldn't even know where to find the applications page, let alone read it. Why not be clear and explicit, and put all relevant information in one place? it's only an extra six letters.

Cause it will not help and you could know that by far.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

OK, you don't believe in clear, unambiguous communication - I think we knew that. Let's leave it, and move on to the real substance of these threads - testing SoG, finding out how to get the best out of it, and deciding whether it's fit to be promoted beyond Beta status yet.

1) any comment on the mis-matched contents of the various MultiBeam_Kernels_r3500.cl files - in particular, the extra lines which have appeared in MB8_win_x86_SSE2_OpenCL_ATi_r3500 (only)?

2) I reported some days ago that I was getting good validation with MB8_win_x86_SSE3_OpenCL_NV_SoG_r3500, but had one residual concern - inconclusive validation against CPU builds, when tasks overflow late into the run. The examples I posted then will probably have been purged by now, but here are a couple of fresh ones visible today.

blc5_2bit_guppi_57451_65998_HIP117463_0013.15104.831.17.26.243.vlar
blc5_2bit_guppi_57451_67643_HIP117473_OFF_0018.9192.831.18.27.101.vlar

1) any comment on the mis-matched contents of the various MultiBeam_Kernels_r3500.cl files - in particular, the extra lines which have appeared in MB8_win_x86_SSE2_OpenCL_ATi_r3500 (only)?

Use the biggest one.

2) I reported some days ago that I was getting good validation with MB8_win_x86_SSE3_OpenCL_NV_SoG_r3500, but had one residual concern - inconclusive validation against CPU builds, when tasks overflow late into the run. The examples I posted then will probably have been purged by now, but here are a couple of fresh ones visible today.

blc5_2bit_guppi_57451_65998_HIP117463_0013.15104.831.17.26.243.vlar
blc5_2bit_guppi_57451_67643_HIP117473_OFF_0018.9192.831.18.27.101.vlar

Invalids on overflow will happen until validator will be changed. What exactly interesting in these ones?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

What exactly interesting in these ones?

               CPU     SoG

Spike count:    21      17
Autocorr count:  1       1
Pulse count:     6      10
Triplet count:   2       2
Gaussian count:  0       0

Spike count:    23      19
Autocorr count:  2       2
Pulse count:     5       9
Triplet count:   0       0
Gaussian count:  0       0

Those are big discrepancies for the validator to overcome - I'm not sure whether they will be able to do it, while at the same time preventing the database being polluted with false positives.

As I said in my earlier report, I'm presuming that it's an artefact of changed signal processing order. It may be necessary to grit our teeth and accept the inefficiency of reprocessing - late overflows are relatively rare - but I thought it was worth remarking on anyway.

What exactly interesting in these ones?

               CPU     SoG

Spike count:    21      17
Autocorr count:  1       1
Pulse count:     6      10
Triplet count:   2       2
Gaussian count:  0       0

Spike count:    23      19
Autocorr count:  2       2
Pulse count:     5       9
Triplet count:   0       0
Gaussian count:  0       0

Those are big discrepancies for the validator to overcome - I'm not sure whether they will be able to do it, while at the same time preventing the database being polluted with false positives.

As I said in my earlier report, I'm presuming that it's an artefact of changed signal processing order. It may be necessary to grit our teeth and accept the inefficiency of reprocessing - late overflows are relatively rare - but I thought it was worth remarking on anyway.

Where false positives here?

Exactly for signal validation questioning reasons I added signal printings to stderrs of all non-CUDA apps and Petry was kind enough to implement the same for CUDA builds too.
So better use this tool than just look for signal counts.

Interesting ones could be those where highest icfft differs to more than 1.
[icfft not reported so look at the chirprate instead. If it fdiffer for more than 1-2 chirp resolution steps]
And to claim there is false positive one need to reprocess task with lifted number of signals to report and then compare all what CPU would found with what GPU report. If GPU reports smth that doesn't subset of CPU report on unrestricted task, only then it will be false positive (that should be dealt with, of course).

P.S.
For one of tasks I see:
last result in GPU:
Spike: peak=24.47977, time=15.39, d_freq=1255060294.08, chirp=-39.401, fft_len=8k
last result in CPU:
Spike: peak=24.42041, time=15.39, d_freq=1255060294.06, chirp=-39.584, fft_len=8k

So, chirp difference is 0.183

Typical chirp step is:
<chirp_resolution>0.1665</chirp_resolution>

So, I would say too close to pretend to false positive and to worth further exploration.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

I wasn't meaning to suggest that this particular class of tasks would be passed through as false positives: rather, that changing the validator, and perhaps allowing greater tolerances for initial strong-similarity validation without a recheck (your initial suggested solution) might perhaps open the door a crack for other cases to slip through.

I wasn't meaning to suggest that this particular class of tasks would be passed through as false positives: rather, that changing the validator, and perhaps allowing greater tolerances for initial strong-similarity validation without a recheck (your initial suggested solution) might perhaps open the door a crack for other cases to slip through.

I did not propose to reduce strong-similarity per reported signals.
Matching subset should match as precisely as before.
FYI, current validation mechanism allows some really broken signals to slip through by arbitrarity of canonical result selection and tolerance to not full-matching signals.
So nothing new under the moon as they say.

Though always worth to check for possible bugs all transitions starting from 8.12 actually did not touch search code so probability of new validation issues quite low. Of course search for possible older bugs should continue.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

selected SSE4.1 and cuda42 options for MS, SSE3 for AP

And how this related to OpenCL 8.12 support thread?

Perhaps I made some wrong choice in setting up for testing the new OpenCL application, but it wasn't obvious how to select for OpenCL instead.

Though always worth to check for possible bugs all transitions starting from 8.12 actually did not touch search code so probability of new validation issues quite low. Of course search for possible older bugs should continue.

Yes, that's what I did to Jason with a similar investigation of inconclusives before the first public release in - that's why we had a late transition from x41zh to x41zi, with increased arithmetic precision to match tighter validation tolerances. That slowed the app down, but yielded more first-time validations and fewer resends. That's possibly what we ought to be doing with the stock apple-darwin builds, BTW - I didn't mention them to reduce the chatter, but they're an ongoing problem.

And on the other subject, how significant is the MultiBeam_Kernels_r3500.cl change? Is it worth a Beta5, a silent refresh, or simply a wait until the next revision? As you'll have seen from the discussion in the Beta Installer thread, currently people will only get the newer file for SoG if they also select ATi (non-HD5) during the same run.

Though always worth to check for possible bugs all transitions starting from 8.12 actually did not touch search code so probability of new validation issues quite low. Of course search for possible older bugs should continue.

Yes, that's what I did to Jason with a similar investigation of inconclusives before the first public release in - that's why we had a late transition from x41zh to x41zi, with increased arithmetic precision to match tighter validation tolerances. That slowed the app down, but yielded more first-time validations and fewer resends. That's possibly what we ought to be doing with the stock apple-darwin builds, BTW - I didn't mention them to reduce the chatter, but they're an ongoing problem.

And on the other subject, how significant is the MultiBeam_Kernels_r3500.cl change? Is it worth a Beta5, a silent refresh, or simply a wait until the next revision? As you'll have seen from the discussion in the Beta Installer thread, currently people will only get the newer file for SoG if they also select ATi (non-HD5) during the same run.

non GPU_TWINCHIRP paths exactly the same. So for all current builds additions are just as silent parts of human genome.
Will "speak" loud in the future though ;)

[Actually, for the sake of accuracy, not exactly the same. Calling sequence the same, but new kernels will go through CL compiler still.
]

And so: no, installer rebuild doesn't required. Supply single CL file - any of them.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.