I have a Ryzen 9 3900XT with two AMD GPUs: R9 Nano and R9 280X. If I put Gamma onto beta, it breaks every single task with a computation error within seconds of starting. But all my other computers (a variety of Intels, some old some new) all with R9 280X cards work fine. I noticed the dodgy computer is getting tasks labelled "Gamma-ray pulsar binary search #1 on GPUs (FGRPopencl2-ati)". The working computers get the same but with "(FGRPopencl1K-ati)" on the end. Why is one machine getting different ones? Is it because of the Nano? Whatever they are, they don't run on the Nano or the 280X.
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
Copyright © 2024 Einstein@Home. All rights reserved.
I notice the "2" tasks are
)
I notice the "2" tasks are labelled as beta on the applications page. The 1K ones are not. Strange only one of my computers is given beta work.
I'm getting "The network BIOS session limit was exceeded", which is an error usually found when connecting across a network:
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
the "2" app means it requires
)
the "2" app means it requires OpenCL 2.0 (this app was built with features in the OpenCL 2.0 spec and are not supported if you have a device or driver with less than 2.0 support). the project will check the driver details and see if OpenCL 2.0 is supported. driver details are communicated to the project via BOINC in the sched RPC. if your system reports 2.0 support, and you have beta tasks turned on, then the project green-lights you for the 2.0.
the simple explanation to why your R9 Fury gets the "bad" tasks, is because it supports OpenCL 2.0 and your other cards do not.
the root cause of the errors seems to be that even though the drivers and device claim to be supporting openCL 2.0, they really dont support it correctly, or arent supporting all features of 2.0. driver issues are ubiquitous with AMD.
just turn off beta tasks.
or edit/lock your coproc file and force it to display only opencl 1.2 support
_________________________________________________________________________
When the bad machine
)
When the bad machine downloads 2, it tries to run it on both cards (Fury and Tahiti) and they both fail. The Tahiti on it (and the machines that don't get given those tasks) are OpenCL 1.2, the Fury is 2.0. This is reported in Boinc at startup. Actually that Fury does have trouble wi9th a couple of games the Tahiti is ok with. I'll go with AMD bug.
I don't want to turn off beta as I'm doing the BRP7. I'll try the coproc edit, that sounds like a good idea.
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
Peter Hucker of the Scottish
)
but as has been mentioned many times before, BOINC only communicates device info for the "first/best" GPU to the projects. the OpenCL 2.0 differentiation happens at the scheduler level, not the application level. as far as the project is concerned, the host has two R9 Fury GPUs, and meets the OpenCL 2.0 criteria so it gets sent the application/task. on the client side, BOINC doesn't inherently know that GPU1/device1 can't run the task. it's just going in the normal FIFO order and running the task as it comes up that's why it runs on both GPUs. hypothetically, if for example the drivers were fine and the R9 Fury could actually process it, you'd have to specifically exclude GPU1/device1 from that plan class (in cc_config) to avoid execution on it.
_________________________________________________________________________
The Fury is d1, Tahiti d0. I
)
The Fury is d1, Tahiti d0. I guess it must be best, not first.
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.