|
1)
Message boards :
Number crunching :
Older GPUs not working
(Message 3476)
Posted 3 Apr 2023 by JStateson Post: Was running only SETI, Einstein and Milkyway in Ubuntu 18.04 Never tried Numberfields and no longer use these cards in Ubuntu due to the difficulty of rolling back to the kernel blessed by AMD. s9000 and s9050 have the Tahiti chipset as do the HD-7970, 7950, R9 and all variations of Tahiti just have more memory and use more or less cores The Tahiti problem was discussed before here note the only difference is the memory and number of cores: https://www.techpowerup.com/gpu-specs/radeon-hd-7970.c296 https://www.techpowerup.com/gpu-specs/firepro-s9000.c1879 The s9100, s9150 and Mi25 are recognized as w9100, w9150 and wx9100 respectively in windows 10 and work fine on all projects. These boards all go for under $100 USD used but need a good DIY fan. The xml file in the slot assigned to Numberfields only recognizes the first card. That does not seem to be a problem even though there are 4 really different cards in the system with the 2.0 OpenCl devices. How is that file generated? Is there a debugging feature that can be enabled by supplying an option in the command line? The following code should never have executed since DIGIT_BIT was defined to be 31 in an earlier include statement. if (DIGIT_BIT>32) {
if( (pow2 & 0xFFFFFFFF)==0 ) { d = 32; pow2 >>= 32; }
}
|
|
2)
Message boards :
Number crunching :
Older GPUs not working
(Message 3474)
Posted 3 Apr 2023 by JStateson Post: That is very strange. The code that's referenced should only be reached under CUDA (the multi-precision words are 64bits in CUDA and only 32bits in OpenCL, hence the error about the shift being too large). I spent some time looking at this as solving puzzles is one of my bad habits plus I am retired. Looking at the .h and .cl I see they are all functionally the same eg: gpuMultiPrecAMD_v402.h pdtKernelAMD_v402.cl pdtKernel_v402.cl gpuMultiPrec_v402.h The app copies them down to a boinc slot and drops the "v402". The one named "amd" is no different than the nvidia one except the name (and the include name) The following are the cpu, intel, nvidia and amd executables. It seems there is no difference between the nvidia and amd so the OpenCL library differenciate. 02/12/2023 09:56 AM 22,536,448 GetDecics_4.00_windows_x86_64 03/31/2023 02:32 PM 22,719,607 GetDecics_4.02_windows_x86_64__opencl_intel 03/31/2023 02:32 PM 22,575,516 GetDecics_4.02_windows_x86_64__opencl_nvidia 02/12/2023 09:55 AM 22,575,516 GetDecics_4.02_windows_x86_64__opencl_amd I did find (I assume) the command line options in the sched_reply xml but they were all empty <file_ref>
<file_name>sf7_DS-16x11_Grp4834097of8000000.dat</file_name>
<open_name>in</open_name>
</file_ref>
<command_line>
</command_line>
</workunit>I tried running in standalone mode by removing the soft links and executing the AMD app in a folder with all the files it needed (that I could guess at) 04/02/2023 07:08 PM <DIR> .
04/02/2023 07:08 PM <DIR> ..
04/02/2023 06:13 PM 349 gpuLookupTable.txt
04/02/2023 06:13 PM 34,028 gpuMultiPrecAMD.h
04/02/2023 06:13 PM 1,061 in
04/02/2023 06:31 PM 8,642 init_data.xml
04/02/2023 06:13 PM 728 mp_int.h
04/02/2023 06:36 PM 0 out
04/02/2023 06:31 PM 124 out.1
04/02/2023 06:13 PM 76,649 pdtKernelAMD.cl
02/12/2023 09:55 AM 22,536,448 test.exe
02/12/2023 09:55 AM 22,575,516 test2.exe
10 File(s) 45,233,545 bytes
2 Dir(s) 1,820,312,457,216 bytes free
C:\Users\jstateson\Downloads\numbers_h110\test>test2When I ran "test.exe" the cpu app runs and seemed to work as the iteration started. Unfortunately "test2.exe", the amd app, did nothing whatsoever. GPU-z showed no load on the GPU. The contents of stderr is C:\Users\jstateson\Downloads\numbers_h110\test>type stderr.txt 19:08:37 (40056): Can't set up shared mem: -1. Will run in standalone mode. GPU Summary String = [CAL|AMDFireProS9050|3|12288MB||102]. Loading GPU lookup table from file. GPU was not found in the lookup table. Using default values: numBlocks = 1024. threadsPerBlock = 32. polyBufferSize = 32768. Anyway, this is as far as I got. I never figured out how the xml file got created. If I run the app without the xml file I get an error and the app closes C:\Users\jstateson\Downloads\numbers_h110\test>test2 C:\Users\jstateson\Downloads\numbers_h110\test>type stderr.txt 20:04:42 (66488): Can't open init data file - running in standalone mode GPU Summary String = . Loading GPU lookup table from file. GPU was not found in the lookup table. Using default values: numBlocks = 1024. threadsPerBlock = 32. polyBufferSize = 32768. 20:04:42 (66488): Can't open init data file - running in standalone mode Error: Failed to obtain OpenCL device id. Error: Failed to initialize OpenCL. I as never able to duplicates that 31 bit error. If you got any ideas let me know. [edit] The AMD app runs fine on my s9100, s9150, VII and MI25 amd boards but fails on the s9000 and s9150 The s90x0 are OpenCL platform 2.1 and device 1.2 whereas the s91x0 are 2.1 and 2.0 My s9000 and s9050 work fine under OpenCl for Einstein and Milkway under windows and I have used them under linux before. |
|
3)
Message boards :
Number crunching :
Older GPUs not working
(Message 3472)
Posted 1 Apr 2023 by JStateson Post: I have seven s9000 and s9050 type GPUs. These are OpenCL 1.2 and run extremely well in Milkyway but fairly slow though useable in Einstein. Their GPU chip is same as the HD-7950 or 7970. Unaccountably, they consistently fail here in NumberFields. GPU-z shows %0 utilization the entire time the app is running. After about 4 hours they generate the following error "C:\Users\JSTATE~1\AppData\Local\Temp\OCL27052T3.cl", line 1941: warning:
shift count is too large
if( (pow2 & 0xFFFFFFFF)==0 ) { d = 32; pow2 >>= 32; }
^My s9100 and s9150 are OpenCl 2.1 and run fine on this project. Their GPU chip is different. Any possibility of getting those older boards to work? I enabled "DEBUG" and "DBG_THREAD" settings in the .h and .cl files but nothing showed up. Code probably did not get that far to print anything but I am just guessing. |