It's ok that the new app version is first crunching thru some of the old workunits, to make sure we didn't break anything or significantly degraded performance even for the code paths that are used only with those old workunits. The support for the old, "tweaked" workunits will stay in the code in case we will again need it later.
The timestamps of 2011 that you might see in the logs or workunit file names refer to the time when the raw data for the workunit was recorded at the radio telescope. This is not crucial for the question we are discussing here.
good:
* this one validated against a CUDA task
* comparing to older openCL tasks of the same host, the new app with the new workunits seems to show a 10-20% performance increase.
still needs improvement:
* CPU usage seems to be higher that for the CUDA app. I'm not sure how much of this is caused by the driver rather than the app itself
* overall performance is in the right ballpark as compared to the CUDA app, but there should be a bit more room for improvement.
Still, I think if this trend is confirmed by more results and validation is successful, we have a release candidate for Einstein@Home. We will have to upgrade the server side BOINC software to a version that supports OpenCL (as here on Albert@Home), tho.
So with your continued help as beta testers for the OpenCL app here, we are now closing in on going into production with the ATI app.
Thanks for the feedback, I think we have seen this particular error also with other apps and it might even be a general BOINC issue...definitley needs some investigation.
I see your host has now a mix of old and new WUs and I understand that the speedup is about 20%. If you can provide any numbers for the Video RAM usage, that would be cool.
It's a mobile workstation, i7-820qm, FirePro Mobility 7820 (Juniper-based).
Driver Package: 8.911.3.3-120309a-136336C
Catalyst version: 11.11
I was running POEM++ OpenCL x3 WU on it.
Pause all running WU.
Exit BOINC.
Re-launch BOINC.
Select Albert WU.
Resume
@ ~0.018%, the screen starts to have multi-color square dots
But it continue running.
Pause Albert WU.
Move mouse/window, dots disappear.
Resume Albert WU.
Driver restarts/recover @ ~0.320%.
Pause Albert WU.
Exit BOINC
Restart machine.
Login, launch BOINC.
Resume Albert WU.
No dots, continue run to completion (I hope).
Hope this can be rectified before release.
clinfo dump:
Number of platforms: 1
Platform Profile: FULL_PROFILE
Platform Version: OpenCL 1.1 AMD-APP (831.4)
Platform Name: AMD Accelerated Parallel Processing
Platform Vendor: Advanced Micro Devices, Inc.
Platform Extensions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices cl_khr_d3d10_sharing
Platform Name: AMD Accelerated Parallel Processing
Number of devices: 2
Device Type: CL_DEVICE_TYPE_GPU
Device ID: 4098
Board name: ATI FirePro M7820
Max compute units: 10
Max work items dimensions: 3
Max work items[0]: 256
Max work items[1]: 256
Max work items[2]: 256
Max work group size: 256
Preferred vector width char: 16
Preferred vector width short: 8
Preferred vector width int: 4
Preferred vector width long: 2
Preferred vector width float: 4
Preferred vector width double: 0
Native vector width char: 16
Native vector width short: 8
Native vector width int: 4
Native vector width long: 2
Native vector width float: 4
Native vector width double: 0
Max clock frequency: 700Mhz
Address bits: 32
Max memory allocation: 536870912
Image support: Yes
Max number of images read arguments: 128
Max number of images write arguments: 8
Max image 2D width: 8192
Max image 2D height: 8192
Max image 3D width: 2048
Max image 3D height: 2048
Max image 3D depth: 2048
Max samplers within kernel: 16
Max size of kernel argument: 1024
Alignment (bits) of base address: 2048
Minimum alignment (bytes) for any datatype: 128
Single precision floating point capability
Denorms: No
Quiet NaNs: Yes
Round to nearest even: Yes
Round to zero: Yes
Round to +ve and infinity: Yes
IEEE754-2008 fused multiply-add: Yes
Cache type: None
Cache line size: 0
Cache size: 0
Global memory size: 1073741824
Constant buffer size: 65536
Max number of constant args: 8
Local memory type: Scratchpad
Local memory size: 32768
Kernel Preferred work group size multiple: 64
Error correction support: 0
Unified memory for Host and Device: 0
Profiling timer resolution: 1
Device endianess: Little
Available: Yes
Compiler available: Yes
Execution capabilities:
Execute OpenCL kernels: Yes
Execute native function: No
Queue properties:
Out-of-Order: No
Profiling : Yes
Platform ID: 000007FEF1FBC9C8
Name: Juniper
Vendor: Advanced Micro Devices, Inc.
Device OpenCL C version: OpenCL C 1.1
Driver version: CAL 1.4.1607 (VM)
Profile: FULL_PROFILE
Version: OpenCL 1.1 AMD-APP (831.4)
Extensions: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_popcnt cl_khr_d3d10_sharing
? I poked through my history and all my wu's have 20110421 in them. I started aborting batches to try and get some new ones, but no dice so far. Unless I am mistaken, the 20110421 is the datestamp for when the data was recorded? Or is that the datestamp from when it was split?
I have the day off tomorrow so I will abort/babysit Boinc to try and get some newer ones.
? I poked through my history and all my wu's have 20110421 in them.
This is not the WU creation date, you can see that one by following the WU link in the results list. It seems that the first "new" WUs were generated around 13:00 UTC on 27th of April already. When looking at your results, you will notice the results will fall into one of two narrow ranges of runtime, where the newer results (newer by WU creation time) run about 20% faster.
In my AMD HD 6850 i'm running 2 boinc projects: albert@home and poem@home (3 gpu wu in 1 cpu). When i download an Albert@home gpu wu, the poem wus entered in "suspended" state and albert@home wu doesn't start - aka, no work on gpu. If i reboot boinc client, the poem wu remain suspended, but albert wu starts and runs ok...
Is this normal??
Hi It's ok that the new app
)
Hi
It's ok that the new app version is first crunching thru some of the old workunits, to make sure we didn't break anything or significantly degraded performance even for the code paths that are used only with those old workunits. The support for the old, "tweaked" workunits will stay in the code in case we will again need it later.
The timestamps of 2011 that you might see in the logs or workunit file names refer to the time when the raw data for the workunit was recorded at the radio telescope. This is not crucial for the question we are discussing here.
Cheers
HB
Hi! I've seen the first
)
Hi!
I've seen the first "new" workunits being completed now, e.g. this one:
http://albertathome.org/workunit/68037
This should give a rough idea what to expect:
good:
* this one validated against a CUDA task
* comparing to older openCL tasks of the same host, the new app with the new workunits seems to show a 10-20% performance increase.
still needs improvement:
* CPU usage seems to be higher that for the CUDA app. I'm not sure how much of this is caused by the driver rather than the app itself
* overall performance is in the right ballpark as compared to the CUDA app, but there should be a bit more room for improvement.
Still, I think if this trend is confirmed by more results and validation is successful, we have a release candidate for Einstein@Home. We will have to upgrade the server side BOINC software to a version that supports OpenCL (as here on Albert@Home), tho.
So with your continued help as beta testers for the OpenCL app here, we are now closing in on going into production with the ATI app.
Cheers
HB
I'm not sure why, but I've
)
I'm not sure why, but I've thrown 3 error recently:
http://albertathome.org/workunit/67888
http://albertathome.org/workunit/66586
http://albertathome.org/workunit/66147
edit:
Upon examination, all the wu's that errored start with this:
7.0.26
Incorrect function. (0x1) - exit code 1 (0x1)
Thanks for the feedback, I
)
Thanks for the feedback, I think we have seen this particular error also with other apps and it might even be a general BOINC issue...definitley needs some investigation.
I see your host has now a mix of old and new WUs and I understand that the speedup is about 20%. If you can provide any numbers for the Video RAM usage, that would be cool.
Cheers
HB
Using this host. It's a
)
Using this host.
It's a mobile workstation, i7-820qm, FirePro Mobility 7820 (Juniper-based).
Driver Package: 8.911.3.3-120309a-136336C
Catalyst version: 11.11
I was running POEM++ OpenCL x3 WU on it.
Pause all running WU.
Exit BOINC.
Re-launch BOINC.
Select Albert WU.
Resume
@ ~0.018%, the screen starts to have multi-color square dots
But it continue running.
Pause Albert WU.
Move mouse/window, dots disappear.
Resume Albert WU.
Driver restarts/recover @ ~0.320%.
Pause Albert WU.
Exit BOINC
Restart machine.
Login, launch BOINC.
Resume Albert WU.
No dots, continue run to completion (I hope).
Hope this can be rectified before release.
clinfo dump:
Number of platforms: 1
Platform Profile: FULL_PROFILE
Platform Version: OpenCL 1.1 AMD-APP (831.4)
Platform Name: AMD Accelerated Parallel Processing
Platform Vendor: Advanced Micro Devices, Inc.
Platform Extensions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices cl_khr_d3d10_sharing
Platform Name: AMD Accelerated Parallel Processing
Number of devices: 2
Device Type: CL_DEVICE_TYPE_GPU
Device ID: 4098
Board name: ATI FirePro M7820
Max compute units: 10
Max work items dimensions: 3
Max work items[0]: 256
Max work items[1]: 256
Max work items[2]: 256
Max work group size: 256
Preferred vector width char: 16
Preferred vector width short: 8
Preferred vector width int: 4
Preferred vector width long: 2
Preferred vector width float: 4
Preferred vector width double: 0
Native vector width char: 16
Native vector width short: 8
Native vector width int: 4
Native vector width long: 2
Native vector width float: 4
Native vector width double: 0
Max clock frequency: 700Mhz
Address bits: 32
Max memory allocation: 536870912
Image support: Yes
Max number of images read arguments: 128
Max number of images write arguments: 8
Max image 2D width: 8192
Max image 2D height: 8192
Max image 3D width: 2048
Max image 3D height: 2048
Max image 3D depth: 2048
Max samplers within kernel: 16
Max size of kernel argument: 1024
Alignment (bits) of base address: 2048
Minimum alignment (bytes) for any datatype: 128
Single precision floating point capability
Denorms: No
Quiet NaNs: Yes
Round to nearest even: Yes
Round to zero: Yes
Round to +ve and infinity: Yes
IEEE754-2008 fused multiply-add: Yes
Cache type: None
Cache line size: 0
Cache size: 0
Global memory size: 1073741824
Constant buffer size: 65536
Max number of constant args: 8
Local memory type: Scratchpad
Local memory size: 32768
Kernel Preferred work group size multiple: 64
Error correction support: 0
Unified memory for Host and Device: 0
Profiling timer resolution: 1
Device endianess: Little
Available: Yes
Compiler available: Yes
Execution capabilities:
Execute OpenCL kernels: Yes
Execute native function: No
Queue properties:
Out-of-Order: No
Profiling : Yes
Platform ID: 000007FEF1FBC9C8
Name: Juniper
Vendor: Advanced Micro Devices, Inc.
Device OpenCL C version: OpenCL C 1.1
Driver version: CAL 1.4.1607 (VM)
Profile: FULL_PROFILE
Version: OpenCL 1.1 AMD-APP (831.4)
Extensions: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_popcnt cl_khr_d3d10_sharing
-- terencewee* Sicituradastra.
RE: I see your host has
)
? I poked through my history and all my wu's have 20110421 in them. I started aborting batches to try and get some new ones, but no dice so far. Unless I am mistaken, the 20110421 is the datestamp for when the data was recorded? Or is that the datestamp from when it was split?
I have the day off tomorrow so I will abort/babysit Boinc to try and get some newer ones.
p2030.20110421.G41.29-00.40.S
)
p2030.20110421.G41.29-00.40.S.b0s0g0.00000_744_0 using einsteinbinary_BRP4 version 123 (atiOpenCL)
GPU-Z & Task Manager:
http://img7.imageshack.us/img7/7159/p203020110421g41290040s.jpg
RE: RE: I see your host
)
This is not the WU creation date, you can see that one by following the WU link in the results list. It seems that the first "new" WUs were generated around 13:00 UTC on 27th of April already. When looking at your results, you will notice the results will fall into one of two narrow ranges of runtime, where the newer results (newer by WU creation time) run about 20% faster.
Cheers
HB
p2030.20110421.G41.29-00.40.S
)
p2030.20110421.G41.29-00.40.S.b0s0g0.00000_1264_1
http://img809.imageshack.us/img809/154/b0s0g00000012641.jpg
In my AMD HD 6850 i'm running
)
In my AMD HD 6850 i'm running 2 boinc projects: albert@home and poem@home (3 gpu wu in 1 cpu). When i download an Albert@home gpu wu, the poem wus entered in "suspended" state and albert@home wu doesn't start - aka, no work on gpu. If i reboot boinc client, the poem wu remain suspended, but albert wu starts and runs ok...
Is this normal??