Posts by Raistmer


log in
1) Message boards : Number crunching : Call for testers: AP 7.08 in test on beta (Message 1656956)
Posted 3 days ago by Profile Raistmer
Those 3 GPU builds of AstroPulse that in test on beta currently have additional feature to be configured per-device basis.
This allows hosts with very different GPU capabilities still feel fine.
Unfortunately, plan classes under that apps were released don't allow to use this feature for stock configs. only with anonymous setup.

Please, reissue very same binaries (under AP v 7.07 if required) but with updated plan classes and additional zero-size (just as for cmdline params we use already) file.

Name of file differs for all 3 builds that allows their coexistence on single host.

Here is example what was added to app_info.xml to make per-device config working for ATi devices:

<file_info>
<name>AstroPulse_ATi_config.xml</name>
</file_info>


<app_version>
<app_name>astropulse_v7</app_name>

<file_ref>
<file_name>AstroPulse_ATi_config.xml</file_name>
<open_name>AstroPulse_ATi_config.xml</open_name>
</file_ref>
</app_version>

Hope this info is enough to make such improvement.
Also, this feature already described in ReadMe files that already distributed from servers.

File names for other 2 GPU types:
AstroPulse_NV_config.xml
AstroPulse_iGPU_config.xml

With generalized pattern:

Name of this config file:
AstroPulse_<vendor>_config.xml where vendor can be ATi, NV or iGPU.

Description of usage already in ReadMe file.
2) Message boards : Number crunching : Call for testers: AP 7.08 in test on beta (Message 1656925)
Posted 3 days ago by Profile Raistmer
Check if per-device config supported now for stock.
Check how builds handle overflows.
Check that NV build accept 341.44 driver for FERMI and refuses those that broken.
And finally, check new OS X OpenCL stock MB.
3) Message boards : Number crunching : @Pre-FERMI nVidia GPU users: Important warning (Message 1655670)
Posted 7 days ago by Profile Raistmer
Summary: drivers starting from 340.52 through 341.44 (not including) are inappropriate for using with pre-FERMI devices and OpenCL AstroPulse.
Either use older driver or upgrade to 341.44.
4) Message boards : Number crunching : @Pre-FERMI nVidia GPU users: Important warning (Message 1655560)
Posted 7 days ago by Profile Raistmer
So it isn't fixed?
don't upgrade to the latest drivers?

Bug about that this thread was started is fixed in 341.44.
Another bug wasn't but it exists in older drivers too.
5) Message boards : Number crunching : Intel GPU (Message 1654272)
Posted 10 days ago by Profile Raistmer
My tests with Intel vTune did not show me any apparent cause differences when running the iGPU to not.

Would it show memory bus overloading anyhow?
6) Message boards : Technical News : /dev/null (Mar 16 2015) (Message 1654144)
Posted 11 days ago by Profile Raistmer
I think this was due to a spurious disk error, but informix was in a sad state. I got it kinda back up and running Sunday night, but have been spending all day repairing/checking that index (and the whole database) so we haven't been able to assimilate any results for a while. Once again: soon.

- Matt

RAID5 used?


Don't tell me you belong to BAARF? :-P

LoL, no. But mention of BAARF lead to answer to my unspoken question: RAID5 (even being used) doesn't check parity on read. Hence "spurious disk error" quite possible. I had better impression about error-correction abilities of such arrays before.
http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt
7) Message boards : Number crunching : Intel GPU (Message 1654122)
Posted 11 days ago by Profile Raistmer
[quote]
It means the GPU task requires a lot of CPU attention or the memory bus is overcommitted and the CPU and GPU are both starving. I'd try freeing up a core.

Or overheating/power over-consume and freq lowering as result.
Modern CPUs have too many reasons to voluntarily downclock in default configs.
8) Message boards : Number crunching : Intel GPU (Message 1654120)
Posted 11 days ago by Profile Raistmer
The Readme also suggests freeing a CPU core so the GPU is serviced sooner when it needs to be told what to do. I'm skeptical about that, it would have to improve GPU productivity a lot to make up for not crunching on one of the 4 CPU cores.
Joe


Better to use -cpu_lock option and use all CPU cores for crunching.
I use such config on own iGPU.
9) Message boards : Technical News : /dev/null (Mar 16 2015) (Message 1653862)
Posted 12 days ago by Profile Raistmer
I think this was due to a spurious disk error, but informix was in a sad state. I got it kinda back up and running Sunday night, but have been spending all day repairing/checking that index (and the whole database) so we haven't been able to assimilate any results for a while. Once again: soon.

- Matt

RAID5 used?
10) Message boards : Number crunching : Intel® iGPU AP bench test run (Message 1653703)
Posted 12 days ago by Profile Raistmer
For my AMD APU running an ATI OpenCL build, GPU-Z shows almost all the memory used is dedicated, about 269 MB while doing the single pulse processing with unroll 12, and about 102 MB during the FFAs. Dynamic is around 17 MB. Some MB7 testing a couple of months ago which caused the heavy memory usage to be dynamic was clearly slower.

The GPU portion of that AMD APU is derived from GPUs designed for standalone cards, of course, while Intel's design has been meant for embedded from the start. The AMD and Intel OpenCL implementations differ, too. IOW, I have no idea if that observation is meaningful.
Joe


IMHO it's relevant to iGPU too. Cause it's more about memory handling by CPU, not GPU-specific.
Quite probably dedicated memory has caching switched off and writeback active. Cause both APU and iGPU share system memory for GPU part OS memory range setup will matter. Another possibility that "dynamic" is swap area that OS' driver uses when its dedicated buffer overflows. Then penalty will be high too cause additional buffer copy required prior kernel invocation (and again, not GPU-specific).
11) Message boards : News : Astropulse is generating work again (Message 1653178)
Posted 14 days ago by Profile Raistmer
Actually "not generating work again" title should read :)
Stuck since yesterday at least.
12) Message boards : Number crunching : The Highest Ranked SETI AMD Host is a MAC: Time for a STOCK MAC APP? (Message 1652044)
Posted 17 days ago by Profile Raistmer


Success!

Check next rev please too.
13) Message boards : Number crunching : The Highest Ranked SETI AMD Host is a MAC: Time for a STOCK MAC APP? (Message 1651878)
Posted 17 days ago by Profile Raistmer
And after that check revision 2871 - will it work on OS X ?
It has more generalized approach to kernel launch geometry, but implements this approach only on FindSpike32 kernel. All others will use max device limit for now.
14) Message boards : Number crunching : The Highest Ranked SETI AMD Host is a MAC: Time for a STOCK MAC APP? (Message 1651857)
Posted 17 days ago by Profile Raistmer
Ok, try revision: 2870 for OpenCL MultiBeam.
That WG size limiting code wasn't on my workcopy too so I added it. Also other improvements.

Regarding AP: If you download whole folder you need to delete AP folder after and rename AP_BLANKIT folder to AP one. All this should be not needed if SVN would be used properly. AP and AP_BLANKIT belongs to different branches actually.
15) Message boards : Number crunching : The Highest Ranked SETI AMD Host is a MAC: Time for a STOCK MAC APP? (Message 1651572)
Posted 18 days ago by Profile Raistmer
Any luck on assigning the WG to Apple GPUs yet? If there is a workaround in the repository somewhere has anyone found it?
I've concluded my MB7 CPU work and would like to finish MB work before moving on to the AP project.

Wait a little, under investigation for now.
16) Message boards : SETI@home Science : Strange Question: Time Difference between stars (Message 1651148)
Posted 19 days ago by Profile Raistmer
Subsequent work on the two-slit experiment has offered alternative information on why we see what we see.

Can you explain the idea of a "Superposition of two states" and why only two if you believe Feynman.


Any state can be represented as summation on full orto-normal basis states with corresponding weight coefficients.
It can be sum of some finite number of elements (if basis finite), it can be sum of infinite number of elements.
There are books that can help, for example this one: https://archive.org/details/QuantumMechanics_104
17) Message boards : Number crunching : Intel® iGPU AP bench test run (Message 1651143)
Posted 19 days ago by Profile Raistmer
thanks. Similar to HD2500. Nothing said about wave size though.
Try all values then and will see.
18) Message boards : Number crunching : @Pre-FERMI nVidia GPU users: Important warning (Message 1651110)
Posted 19 days ago by Profile Raistmer
So, bug still there.
19) Message boards : Number crunching : Intel® iGPU AP bench test run (Message 1650994)
Posted 20 days ago by Profile Raistmer
clInfo.
20) Message boards : Number crunching : @Pre-FERMI nVidia GPU users: Important warning (Message 1650868)
Posted 20 days ago by Profile Raistmer
I repoted that fix works back to NV and closed bug report.
Awaiting info about sync/async bug status.


Next 20

Copyright © 2015 University of California