Quote:1) Selecting a GPU load percentage seems fairly trivial.
At startup, after retrieving the GPU capabilites (# of shaders), simply scale and use that number.
All this assumes is that # of shaders is an input to some function in the application.
no, you can not scale at runtime when you are developing for performance.
Quote:2) Optimizing "workload parameters" is worthy goal only if they have a significant effect on efficiency.
For this to work, it would be best if they can be formulated into a linear equation with independent parameters, a convex solution (no local maximums), with Hashes/s as the output.
After reaching something of a steady state, "tweak" each parameter (up and down) to maximize Hashes/s.
A separate thread can handle this, but it assumes that the parameters can be adjusted after startup.
no, it can not, see my original post. its about the 90% thing.
Quote:3) Scaling back a GPU so it doesn't exceed a maximum temperature is a simple feedback and control system, similar to the heater thermostat on your wall.
This would require a monitoring thread (in Java I'd implement it as a repeating timer that fires an event every 0.5s or so).
If the maximum temperature is approached, scale back the number of available shaders.
As before, it assumes that the application architecture uses something like a job queue, where the number of workers (i.e. shaders) can be changed at run time.
And it assumes that the temperature reading from the GPU is accurate.
this is implemented by the driver. it automatically clocks down if some threshold is reached.