meaning of negative and zero for GPU utilization factor
15 Dec 2015 20:46:11 UTC
Topic 198344
(moderation:
I'm familiar in general terms with the functional use and meaning of such values for the GPU utilization factor as:
[pre]1.00: run a single task at a time of this type on the GPU
0.50: run two
0.33: run three[/pre]
I have kept this value for FGRP (which I don't run) at -1 for many months. I think perhaps I believed that with a negative value no tasks would run, if somehow my other settings would have allowed assignment.
Just now I tried to update something else on an Einstein settings location (venue) and the web coding generated an error message, advising me I had an illegal value, and that the range was Min: 0.0 / Max: 1.0 / Default: 1.0
Can anyone advise what the practical effect of specifying zero here would be? Naively the consistent meaning would be that an infinite number of tasks would run simultaneously--or more practically, that all tasks successfully downloaded to the host of this type would be attempted to run simultaneously. That seems a curious intended meaning. Does anyone know what a negative value used to cause to happen?
meaning of negative and zero for GPU utilization factor
)
Indeed - i guess it will be limited by CPU allocation - give it a try and see what happens!
I think this stemmed from the days of GPU and CPU versions of the same app and setting it to -1 stopped the GPU versions being run.
See Fermi LAT Gamma-ray pulsar search #3 "FGRP3"
RE: Just now I tried to
)
Because the use of -1 was a quick hack for when there was a FGRP GPU app, this value is no longer needed to 'turn off' the now non-existent GPU tasks. With the deploying of the updated server code, the allowed values must have reverted to the ones that existed prior to the hack - ie the hack has effectively been dropped and the system sees the value of -1 as illegal. I still have -1 and if I was editing those prefs and forced to change, I'd just put the default '1'. It has no effect at the moment but if an FGRP GPU app were ever released, this would be the safe setting.
I can't recall ever seeing the consequences of setting zero actually defined - but that doesn't mean it wasn't. I would expect that setting to cause some upper limit concurrent tasks value - perhaps something like 10 (from a setting of 0.1) which I remember seeing someone using on a 7970 quite some time ago. I've never tested it but I would hope (since it is legal to set zero) that there would be a simple test that ensures a setting less than 0.xx is treated as exactly 0.xx. I think 0.10 might be appropriate for that limit. It's a bit hard to imagine anyone needing to try more than 10 concurrent :-).
Cheers,
Gary.
I was just wondering what
)
I was just wondering what happened to the FGRP GPU app.
Did not enough people run it to make it worthwhile.
John
It was withdrawn because of
)
It was withdrawn because of driver related problems - I forget the details. Also, it required a lot of the calculations to be done on the CPU so was quite inefficient in using the GPU.
With advanced LIGO data to arrive at some point, I presume that new GW apps will be where the development effort is going at the moment.
Cheers,
Gary.
The FGRP3 GPU app version had
)
The FGRP3 GPU app version had only the FFT done on the GPU, everything else on the CPU.
In FGRP4 the share of FFT on the overall computation time is even less than it was in FGRP3, so we decided not to make a similar app for FGRP4, because it would have been even less efficient than in FGRP3.
The new FGRP "binary" search that we are currently developing will probably feature a GPU version at some later stage. But first we need to get it working at all.
As for the "GPU utilization factor" a value of 0 means no value set at all (effectively equal to 1), and a negative value indeed means "don't run GPU tasks of this app at all".
BM
BM