Posts by JStateson

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).

The OpenCL and CUDA apps use much of the same code, and the differences are handled via preprocessor directives. Here is the best theory I have for what is happening: You have a system environment variable named "CUDA" so when your openCL compiler reaches a point in the code with the "#ifdef CUDA" directive, it ends up setting the multi-precision word larger than it should, and will also set other parameters incorrectly. If this is what's happening, I would first check your system variables for "CUDA", otherwise it could be the openCL implementation on your system that is setting the CUDA directive. On windows, I believe the openCL implementation is part of a system dll file, so not sure how to handle that. Do you know how to get the exact command line that your openCL compiler is using?


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>test2


When 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.





Main page · Your account · Message boards


Copyright © 2026 Arizona State University