Posts by Eric Driver

1) Message boards : News : Support for Intel GPUs (Message 3178)
Posted 3 days ago by Profile Eric Driver
Post:
My UHD 620 laptop survived the transition to Windows 11 (and preserved the BOINC v7.16.20 installation intact, somewhat to my surprise) - details at host 1232275.

I've put through task 125207453 as a test: it returned a valid result in just under two hours, so there's another data point. I've commented with concern at other projects that their invocation of the -cl-mad-enable OpenCL compiler flag has led to validation errors, especially on this machine: but I would guess that the fused multiply + add opcode is more likely to cause problems with floating point arithmetic, rather than here. Still, I mention it just in case...

This machine is an ultraportable, and after an earlier Windows 10 update, the fan only operates at zero or full speed: that doesn't sound good. I'll keep it in reserve and available for testing, but I won't be running it full time.


Yes, we only use integer ops here.

The good news is the results are correct. This tells me the build process is working and the intel GPUs are capable of compiling the openCL and running it successfully. The only thing I don't like are the run times, but I think this is because the intel GPUs are not powerful enough to handle this app. I look forward to seeing how well the new Intel Arc GPUs fare after they debut next year.

For now I will leave this as a beta app. The following cards have returned successful results: HD500, HD515, Gen9, UHD620, UHD630.
2) Message boards : News : Support for Intel GPUs (Message 3176)
Posted 7 days ago by Profile Eric Driver
Post:
I'm slightly surprised that you've felt the need to research and supply additional data about GPU compute devices. Shouldn't that be made available to you and all other application developers, either by the BOINC platform, or from the manufacturer's driver tools?

I've looked into what is made available to you by BOINC / OpenCL for my iGPUs.

name				Intel(R) HD Graphics 4600	Intel(R) HD Graphics 4600
vendor				Intel(R) Corporation		Intel(R) Corporation
vendor_id			32902				32902
available			1				1
half_fp_config			0				0
single_fp_config		158				158
double_fp_config		0				0
endian_little			1				1
execution_capabilities		1				1
global_mem_size			1360632218			1360632218
local_mem_size			65536				65536
max_clock_frequency		400				400
max_compute_units		20				20
nv_compute_capability_major	0				0
nv_compute_capability_minor	0				0
amd_simd_per_compute_unit	0				0
amd_simd_width			0				0
amd_simd_instruction_width	0				0
opencl_platform_version		OpenCL 1.2			OpenCL 1.2
opencl_device_version		OpenCL 1.2			OpenCL 1.2
opencl_driver_version		10.18.14.5162			10.18.14.5162
device_num			0	
peak_flops			64000000000	
opencl_available_ram		1360632218	
opencl_device_index		0	
warn_bad_cuda			0
That's a pretty eclectic list. The first column is taken from an internal BOINC file called 'coproc_info.xml', and the second from the sched_request_...xml file sent by our clients to your servers. I don't know why the nv and amd fields are present in the iGPU report - presumably it was simpler to use a common data structure across all vendors.

Anyway, numBlocks, threadsPerBlock and polyBufferSize are clearly all missing. How important are they, where can we get them from, and should we ask the BOINC developers to do the heavy lifting?


I think there is some confusion here on the purpose of the lookup table. Let me attempt to clear this up. The parameters "numBlocks" and "threadsPerBlock" are CUDA terminology and describe how to break up the data on the GPU. There is different but equivalent terminology for openCL (I forget the exact names, but it's not important). The optimal parameters are somewhat dependent on the algorithm itself, so the only way to determine them is to run several WUs at different settings to see which is best. The idea was that willing volunteers could do this analysis on their specific card and then report back the optimal setting to be added to the lookup table, with the hope that anybody with that same card would see the same improvement.

For those interested, the testing process is described here. This can be a tedius process, but there have been several volunteers who have helped and have lead to several of the entries in the table. Note that improvement over the default settings is usually less than 10%, so don't expect to see huge performance gains.
3) Message boards : News : Support for Intel GPUs (Message 3173)
Posted 8 days ago by Profile Eric Driver
Post:
It didn't find my nvidia gpu
GPU Summary String = [CUDA|NVIDIAGeForceGTX1650|1|4095MB|49676|300].
Loading GPU lookup table from file.
GPU was not found in the lookup table. Using default values:
numBlocks = 1024.
threadsPerBlock = 32.
polyBufferSize = 32768.


That's because it's not in the lookup table. But no worries, performance should still be relatively good with the default values.



A NVIDIAGeForceGTX1650|1|4095MB|49676|300] is a pretty mid range GPU that I believe has been around for a while. Are the project developers having to build an entire look up table or are there common industry tables available ?


The settings in the lookup table are unique to this project, so yes it would have to be built up manually. The default settings should be pretty good for most cards. The idea was that over time some entries could be added to the lookup table to improve performance on specific cards.
4) Message boards : News : Support for Intel GPUs (Message 3171)
Posted 8 days ago by Profile Eric Driver
Post:
It didn't find my nvidia gpu
GPU Summary String = [CUDA|NVIDIAGeForceGTX1650|1|4095MB|49676|300].
Loading GPU lookup table from file.
GPU was not found in the lookup table. Using default values:
numBlocks = 1024.
threadsPerBlock = 32.
polyBufferSize = 32768.


That's because it's not in the lookup table. But no worries, performance should still be relatively good with the default values.
5) Message boards : News : Support for Intel GPUs (Message 3169)
Posted 8 days ago by Profile Eric Driver
Post:
all my wu finished with miscalculations Error during calculations


According to the stderr, it failed to build the openCL code. At least it exited gracefully instead of the openCL compiler hanging indefinitely which sometimes happens for others.
6) Message boards : News : Support for Intel GPUs (Message 3167)
Posted 9 days ago by Profile Eric Driver
Post:
Update on the glibc problem (only applies to linux users):

The root cause of the problem is that I upgraded my build system in the last year and now have a newer version of glibc. Anyone using a version of glibc older than 2.33 will have this problem. The problem seems to be with a new symbol "fstat" which was not even in the old binaries (according to objdump).

I think the solution is for me to downgrade my system to an earlier version. This will break other things for me, so I am hesitant to do this in the near term. Since this app is a beta version and most runtimes take over 2 hours on the UHD 620/630 cards and hang on lesser cards, it seems like this app will not get much use until the newer intel cards come out in 2022. Hopefully by then I can improve my build system, so we can stop having these compatibility issues.
7) Message boards : News : Support for Intel GPUs (Message 3163)
Posted 11 days ago by Profile Eric Driver
Post:
Aborted both of mine after 9+ hours with no sign of any work being done or any actual GPU usage


Looking at the stderr.txt, it hung while trying to build the openCL, the same problem others are having.
8) Message boards : News : Support for Intel GPUs (Message 3162)
Posted 11 days ago by Profile Eric Driver
Post:
First wu finished after 3h36m:
https://numberfields.asu.edu/NumberFields/result.php?resultid=124655746


Well, at least it finished. But the run time suggests either a bad build of the openCL code or the GPU is not powerful enough for this app. This is the same thing we saw with older Nvidia/AMD cards. Contention may also be playing a role - if other things were running on the GPU at the same time or all the CPU cores were maxed out (recall, the app needs a small portion of a cpu core).
9) Message boards : News : Support for Intel GPUs (Message 3161)
Posted 11 days ago by Profile Eric Driver
Post:
If this will help, it ran for 2.5 hours before I aborted all wus.

https://numberfields.asu.edu/NumberFields/result.php?resultid=124654535


If I understand this correctly, it hung while trying to compile the openCL code, and the debug dump occurred as a result of aborting it.
10) Message boards : News : Support for Intel GPUs (Message 3157)
Posted 11 days ago by Profile Eric Driver
Post:
This doesn't look right. From stderr, in running:

GPU Summary String = [CUDA|NVIDIAGeForceGTX1660SUPER|2|4095MB|47212|300][INTEL|Intel(R)HDGraphics4600|1|1297MB||102].
Loading GPU lookup table from file.
GPU found in lookup table:
  GPU Name = GTX1660.
  numBlocks = 8192.
  threadsPerBlock = 32.
  polyBufferSize = 262144.
The "Intel HD Graphics 4600" is right (present on the machine, OpenCL driver installed, known to BOINC, ready for use), but the GPU Name and (probably) metrics are from the wrong manufacturer.


This is just a flaw with the lookup mechanism - it found your GTX1660 in the lookup table and decided to use those parameters. I need to create a separate lookup table for the intel GPUs.

If you're inclined to fiddle with the lookup table, all you need to do is remove the entry for the 1660 and add a line for the Intel gpu. The only requirement is the name must be a substring of the GPU summary string (for example "HD Graphics 4600" would work). You would also want to reduce the numBlocks to something smaller, like 512. ThreadsPerBlock could stay at 32. ( I would need to study the Intel architecture to find more optimal settings).

Note: using the settings for the GTX1660 might be the cause of the problem you are seeing, because the Intel card probably doesn't have the required resources.
11) Message boards : News : Support for Intel GPUs (Message 3156)
Posted 11 days ago by Profile Eric Driver
Post:
I am not familiar with Intel's lineup of GPUs. I did a little research, and it appears they rank pretty low compared to Nvidia and AMD cards. I'm thinking the UHD 630 might be as low as we can go without hanging the GPU. It looks like the soon to be released Arc Alchemist should do very well.
12) Message boards : News : Support for Intel GPUs (Message 3155)
Posted 11 days ago by Profile Eric Driver
Post:
On my J4105 with Ubuntu 20.04 all wu crashed with:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found
https://numberfields.asu.edu/NumberFields/result.php?resultid=124652101

After upgrade to Ubuntu 21.04 it run.

On two host with win10 wu are running.


Thanks for the feedback! Yes, looks like the old GLIBC problem is back. I'll put that on my to do list.
13) Message boards : News : Support for Intel GPUs (Message 3152)
Posted 11 days ago by Profile Eric Driver
Post:
Still running, after an hour and three quarters. I'm even more convinced it's stalled, so I'll have a deeper dig later.

Workunit has settings

             <rsc_fpops_est>30000000000000.000000</rsc_fpops_est>
    <rsc_fpops_bound>700000000000000000000.000000</rsc_fpops_bound>
That means that BOINC will allow it to run for over four centuries before it intervenes to abort it. I don't think I've quite got that much patience...


Thanks for the feedback, Richard!

When these tasks stall that is usually a sign that the openCL compiler is hung. And that is probably why the boinc_task_state.xml file is not present, as I am guessing that gets created after the openCL code is built. We saw this same thing with the AMD app version, and it's dependent on the particular openCL driver and also the card.

Probably best to just abort them when you see this behavior.
14) Message boards : News : Support for Intel GPUs (Message 3151)
Posted 11 days ago by Profile Eric Driver
Post:
I am seeing tons of WUs sent out (over 4000) so I am setting the beta flag again.

Most are in the init phase, but there are several successful results, so that is encouraging. The successful ones appear to be "UHD Graphics 630"
15) Message boards : News : Support for Intel GPUs (Message 3144)
Posted 12 days ago by Profile Eric Driver
Post:
My device is an i5-7300u running Windows 10. In the preference section I marked "Intel GPU" and "accept test apps". So far I haven't gotten any WU's. This is the only answer I am getting on the message board:

18.11.2021 08:01:10 | NumberFields@home | update requested by user
18.11.2021 08:01:14 | NumberFields@home | Project requested delay of 31 seconds


Not sure what is wrong. I removed the beta designation just in case that is the cause. When I have some time later I will dig deeper into this.
16) Message boards : News : Support for Intel GPUs (Message 3141)
Posted 12 days ago by Profile Eric Driver
Post:
No option to select Intel GPU in preferences.
Please can you fix?


I found the problem. The server code assumes the plan class name contains the string "intel_gpu". I was using just "intel".

The option now shows up in the preferences.
17) Message boards : News : Support for Intel GPUs (Message 3139)
Posted 12 days ago by Profile Eric Driver
Post:
I just added support for Intel GPUs. There are 2 versions - 64 bit linux and 64 bit windows, both require openCL 1.1 or higher.

I don't have an Intel GPU, so I can't test them. But it's the same openCL code that works on other GPUs, so in theory they should work. For the linux version, it was just a matter of downloading the Intel openCL SDK and then linking against Intel's include files and libraries. For the windows version, I cross compiled using mingw64 as I do with AMD/Nvidia cards.

Since they are new and untested, I made them beta apps.
18) Questions and Answers : Web site : Certificate problem (Message 3137)
Posted 23 days ago by Profile Eric Driver
Post:
When I clicked on the certificate to view it. This displays on the top:
Warning: time() expects exactly 0 parameters, 1 given in /home/boincadm/projects/NumberFields/html/user/cert1.php on line 27

Also the time of the cert displays that this year is 1970. This is the website error or my computer has problem ?


I don't know what that warning means. But it looks like you are successfully returning results, so maybe we don't need to worry about it.
19) Message boards : Science : Availability of source code (Message 3134)
Posted 3 Oct 2021 by Profile Eric Driver
Post:
Hi Julien,

Those are all good attempts, however I think the improvement is down in the noise. Recall an average job takes about an hour, so an improvement in nano-seconds is not even noticeable. That subroutine is called less that 1 million times per job, so the overall improvement is still in the milli-seconds. As you can see, improving the performance is not an easy task...
20) Message boards : Number crunching : Proposed New Badge System (Message 3133)
Posted 3 Oct 2021 by Profile Eric Driver
Post:
One thing to keep in mind is the size of the badges (if using the builtin BOINC mechansim) is 48x48 pixels. See this:
https://boinc.berkeley.edu/trac/wiki/BadgeDoc
If your grass images were shrunk to this size, they might not look so great. If sticking with the grass theme, I think it best to stay with the current images, but they could be enhanced. Maybe adding some fireworks to the current images, or flowers like you suggested? Some animation would be cool, like fireworks exploding over the fields which would get bigger and brighter at the higher credit levels. But I'm pretty sure the current BOINC badge system requires static images. This could be a fun project for anyone who wanted to delve into the BOINC code to add support for animated badges.

For reference, here are the current credit levels: 10k, 100k, 500k, 1M, 2M, 5M, 10M, 25M, 50M, 100M, 250M, 500M, 1G, 2G, 5G, 10G. That's a lot of images to generate, hence why I just chose a number on each badge to represent the credit level.

My gut feeling, based on responses in this thread, is that there are very few users who have a strong opinion of the badges. It seems like a waste of time to keep changing the badges around when I have plenty of higher priority tasks. Especially since I don't have much free time these days.


Next 20


Main page · Your account · Message boards


Copyright © 2021 Arizona State University