Is there any way (predefined symbols) to tell at (OpenCL) compile time what the maximum workgroup size or shared data size is?

I would hope that OpenCL will eventually become a more general language where the compilers will do what is necessary to generate functional code regardless of what the inner workings of the GPU are.

Well, usually they do, in NULL provided as size, for example.
But that particular kernel requires precise number of threads and precise amount of shared memory so it failed on some devices.

Unfortunately, fix I proposed earlier will bot work - kernel referenced inside host code.
So, for now such GPUs out of testing.
Will provide 7.01 in next few days I hope.

GPU FLOPS on app page show that only subset of devices suffer from this issue.

The MacOS CPU and ATI GPU versions are out there now as well.

---

The MacOS CPU and ATI GPU versions are out there now as well.

Great!
Meantime 2:0 Brazilia leads :D

OMG, again!

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17271762

That famous crash after computation finish still here :(

EDIT:
normal finish:

TWIN_FFA OCL_ZERO_COPY USE_OPENCL USE_OPENCL_NV OPENCL_WRITE USE_INCREASED_PRECISION SMALL_CHIRP_TABLE COMBINED_DECHIRP_KERNEL BLANKIT
rev 2488
GPU device synched
01:53:48 (3156): called boinc_finish

crash:

TWIN_FFA OCL_ZERO_COPY USE_OPENCL USE_OPENCL_NV OPENCL_WRITE USE_INCREASED_PRECISION SMALL_CHIRP_TABLE COMBINED_DECHIRP_KERNEL BLANKIT
rev 2488


Unhandled Exception Detected...

So, crash inside finish routine?...

  403de6:       8b 0d c0 b5 4e 00       mov    0x4eb5c0,%ecx
  403dec:       8b 15 c8 eb 4c 00       mov    0x4cebc8,%edx
  403df2:       8b 04 91                mov    (%ecx,%edx,4),%eax
  403df5:       50                      push   %eax
  403df6:       ff 15 b8 90 4a 00       call   *0x4a90b8

That seems odd to begin with. It appear to be reading into an array of ints starting at address 0x4eb5c0 (5158336) to get element 0x4cebc8 (5041096) which is at address 0x18264E0 (25322720). These numbers appear to be set at compile time, not at load time,

0x4eb5c0 appears a lot of times in the code. It looks like its a statically allocated structure. The value of the first 4 byte element, possibly a boolean is tested a lot. That's about all I can tell without a symbol table.

---

Another one;
Exit status -1073741819 (0xffffffffc0000005) Unknown error number

The MacOS CPU and ATI GPU versions are out there now as well.

And the other two OpenCL apps for MacOSX will follow.

Important : One of the licensing files currently sent to Macs (and eventually to everyone else) is an old version and needs to be updated : astropulse_7.00_COPYRIGHT.txt

---

_\|/_
U r s

I presume the 1400.00 credit grants are from the --max_granted_credit argument. I'm very curious just how far David's drunken walk statistics is really staggering on the high side. For my host, 94.07 is the lowest I've seen.

                                                                   Joe

Yep, it's the "traditional" settling in period.

---

With tasks grouping by outcome and app type we have good tool for testing outcome analyze. But adding third line - grouping by plan class/app version/device would be even more powerful. To discriminate between CPU/ATi/NV/iGPU results and between different SIMD levels in CPU.

Could we have such improvement in site design in the future?

All my AstroPulse v7 v7.00 (opencl_nvidia_100) tasks failed for Computer 69586 with the same error as task 17284516

---

WU's on first

All my AstroPulse v7 v7.00 (opencl_nvidia_100) tasks failed for Computer 69586 with the same error as task 17284516

Just for info, from OpenCL :

#define CL_INVALID_BINARY                           -42

INFO: can't open binary kernel file: D:\Boinc/projects/setiweb.ssl.berkeley.edu_beta\AstroPulse_Kernels_r2488.cl_QuadroFX880M.bin_V6_TWIN_FFA_33495, continue with recompile...
Error : Building Program (source, clBuildProgram):main kernels: not OK code -42
ptxas : error : Entry function 'GPU_fetch_array_kernel_twin_1D_cl' uses too much shared data (0x4034 bytes, 0x4000 max)

---

_\|/_
U r s

All my AstroPulse v7 v7.00 (opencl_nvidia_100) tasks failed for Computer 69586 with the same error as task 17284516

Just for info, from OpenCL :

#define CL_INVALID_BINARY                           -42

INFO: can't open binary kernel file: D:\Boinc/projects/setiweb.ssl.berkeley.edu_beta\AstroPulse_Kernels_r2488.cl_QuadroFX880M.bin_V6_TWIN_FFA_33495, continue with recompile...
Error : Building Program (source, clBuildProgram):main kernels: not OK code -42
ptxas : error : Entry function 'GPU_fetch_array_kernel_twin_1D_cl' uses too much shared data (0x4034 bytes, 0x4000 max)

I'm seeing a few of these;
GeForce GT 240 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17289630
GeForce GTX 275 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17283660
GeForce GTS 360M http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17289814
Quadro FX 880M http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17283665
GeForce 9300 GE http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17272049

Here's an ATI error, http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17271825

FYI, the server is producing stats files for these versions the same way it did for android apps. I haven't had time to get to classify by GPU memory or model.

http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_i686-pc-linux-gnu.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_i686-pc-linux-gnu__sse2.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_windows_intelx86.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_windows_intelx86__opencl_ati_100.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_windows_intelx86__opencl_intel_gpu_100.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_windows_intelx86__opencl_nvidia_100.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_windows_intelx86__sse.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_windows_x86_64__sse2.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_x86_64-apple-darwin__opencl_ati_mac.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_x86_64-apple-darwin__sse3.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_x86_64-pc-linux-gnu.html
http://setiweb.ssl.berkeley.edu/beta/astropulse_v7_x86_64-pc-linux-gnu__sse2.html

---

Is it normal that these work units of 2013 are referenced in 7.00 version ?



So far, no problem for me with my GPU NVIDIA GT 640 :)
13 work units returned without problems

---

Yes it is normal.

Thats Seti V7 work.
This is Astropulse forum.

---

With each crime and every kindness we birth our future.

Yes it is normal.

Thats Seti V7 work.
This is Astropulse forum.

OMG ! You're absolutely right Mike !
I'm aware that this is a thread dedicated to AP version 7
It's getting too hot in the South of France and I lose my head
Sorry to all for my mistake - I'm a stupid big noob :(
However, for my 13 work units successfully treated, I spoke to AP version 7.

---

Can't say i'm that impressed with the scheduler's decisions, while my Linux running C2D T8100 has been getting a mix of the four app_versions, (none of which have reached their 11 validations):

Application details for host 68093

My i7-2600K/HD7770 host on the otherhand because of the four day difference in release days has managed to complete it's 11 validations for the windows_intelx86 app, it's only managed to get three sse Wu's, and only one sse2 Wu,
now the windows_intelx86 app has completed it's 11 validations, the scheduler seems more inclined to send more and more work for that app version, rather than send work from app_versions that haven't completed their 11 validations,
I expect it'll send them, but not very frequently, and in the meantime lots of hosts will be running a sub-optimal app for a substantial time,

Application details for host 45274

AstroPulse v7 7.00 windows_intelx86  
Number of tasks completed 11 
Max tasks per day 44 
Number of tasks today 12 
Consecutive valid tasks 11 
Average processing rate 16.60 GFLOPS 
Average turnaround time 2.25 days 

AstroPulse v7 7.00 windows_x86_64 (sse2) 
Number of tasks completed 0 
Max tasks per day 33 
Number of tasks today 1 
Consecutive valid tasks 0 
Average turnaround time 0.00 days 

AstroPulse v7 7.00 windows_intelx86 (sse) 
Number of tasks completed 1 
Max tasks per day 34 
Number of tasks today 0 
Consecutive valid tasks 1 
Average processing rate 103.67 GFLOPS 
Average turnaround time 0.96 days 

Claggy

No problems here on my GTX-750.
Still waiting for the first task with blanking (I sure hated these 'wasting' resources) so I can see how much improvement there is.
Are there any other changes in the new v7 version or is it just the improved handling of tasks with blanking ?

Tom

All my AstroPulse v7 v7.00 (opencl_nvidia_100) tasks failed for Computer 69586 with the same error as task 17284516

Look earlier posts in this thread.
Bug already acknowledged and fix committed into sources.