Getting 90% invalid results on Polaris GPU

You need to lose this fixation about getting the GPU "fully loaded" :-).  Just remember, we are talking about having a GPU perform number crunching - not the normal type of workload that various utilities might expect you to be running for something like gaming.  Load will depend very much on how well the compute problem can be 'parallelized' and how much back and forth communication there needs to be with the app running on the CPU.  If a GPU has to 'wait' for CPU support, of course its apparent 'load' will go down.

The gamma-ray pulsar app that analyses the large area telescope data (LAT) on board the Fermi satellite (ie the FGRPB1G app) is very mature and efficiently uses the GPU with little need for a lot of CPU support.  It runs very well singly (x1) but you can get perhaps something like a 10% improvement in throughput if you run x2 - ie. a GPU utilization factor of 0.5.  I have tried x3 (0.33) from time to time and most of the time it will work but the throughput gain is negligible.  Perhaps depending on specific data files being analysed, random fluctuations in crunch time and random errors start creeping in which more than negate any potential gain.  This probably varies with GPU model and GPU settings (frequency, voltage) so you would need to experiment to find out for your own particular hardware.  In the end, it's far simpler not to go beyond x2 and keep the nice stable operation, irrespective of what you think the GPU load might be.

The app that is analysing LIGO data, looking for detections of continuous gravitational wave (GW) emissions from massive rotating bodies like neutron stars, is quite new and relatively immature.  There has been a long running CPU app which is considered to be the benchmark for potentially detecting continuous GW and, to speed up the rate that data can be analysed, there is now a GPU app.  This has been difficult to get running correctly.  It's taken a long time to get it to produce results compatible with the CPU app and it needs way more CPU involvement and support than the GRP app.  I looked through your results and the vast bulk of them are for this app so it's little wonder that you are seeing what you consider to be unacceptably low GPU loads.  Unfortunately, that's just the nature of the beast.  A lot of the calculations still need to be done on the CPU.

I've been experimenting with the GW GPU app on some RX 570 GPUs.  The run is referred to as O2MD where O2 refers to data from observational run #2 of the LIGO detectors and MD stands for Multi-Directional which means multiple specific directions towards specific known pulsars in the Milky Way but as close as possible to earth.  The signals will be incredibly weak so using the closest objects gives the best chance of a detection.  At a later stage, the search will spread to 'All Sky' (O2AS) which will run a lot longer.

For the current O2MD search, I'm currently running x3 (GPU utilization 0.33).  Earlier on I was running x4 but when the attention switched to the Vela pulsar, that soon started producing invalid results so I switched back to x3.   Going from x1 to x2 to x3 to x4 all gave worthwhile improvements in throughput, provided that full CPU support was available.  To achieve that on a Ryzen 2600, I allowed all 6 cores (12 threads) to be available for GPU support duties.

At the end of the day, there is no point running more tasks concurrently than will allow continuous error free operation without having to baby sit the equipment.  Until you get a feel for how things run on your equipment, the best advice I could give would be to 'hasten slowly' :-).

Until you get sufficient experience of where the boundaries are, I would recommend running the FGRPB1G search only and using x2 to start with.  It will most efficiently use your GPU and you could run quite a few CPU tasks on some of your CPU cores.  If running x2 you should make sure there are at least 2 CPU threads available for GPU support.

Do not mix the two GPU searches.  Use your project prefs to 'turn off' the GW search if you choose to run FGRPB1G.  Also make sure you disable 'non-preferred apps'.  The main reason for that is that estimates for crunch times are wrong for both search types but in opposite directions so results for one search type will badly interfere with the estimates for the other type, leading to great difficulty for BOINC to maintain a proper cache of work.  There shouldn't be a problem running FGRPB1G tasks for the GPU and to allow some GW CPU tasks to run on some of the spare CPU cores.  There is a setting that controls the number of cores BOINC can use.  Start at 50% and if that doesn't affect GPU crunch times you could try going a little higher.  At some point, GPU crunch times will be affected and you want to avoid that.

To start with, have low work cache settings (eg 0.5 days max) until BOINC adjusts the estimates to suit the type you have chosen.  Once that happens you could increase to maybe a day or two to protect against any relatively short term work outages.  Another advantage of FGRPB1G is the 14 day deadline which means you could increase the work cache settings a bit more once things were stable.

If you need further advice, please ask and someone is bound to reply :-).