| 1 | = Support for synchronous GPU apps = |
| 2 | |
| 3 | GPU apps run much faster, like 2X, |
| 4 | if their CPU and GPU parts synchronize using busy-waiting instead of interrupts. |
| 5 | (Busy-waiting means it uses 100% of a CPU, |
| 6 | and this process runs at normal OS scheduling priority.) |
| 7 | E.g. you might get a 100 GFLOPS increase in GPU speed |
| 8 | at the expense of 5 GFLOPS of CPU speed. |
| 9 | |
| 10 | However, many volunteers do not want this behavior, |
| 11 | so we can't make it the default. |
| 12 | |
| 13 | This raises several issues: |
| 14 | |
| 15 | == What is the volunteer interface? == |
| 16 | |
| 17 | Possibilities: |
| 18 | * A new preference. |
| 19 | Pros: automatically propagated; available to server. |
| 20 | Cons: too many prefs already. |
| 21 | * Config file flag. |
| 22 | Pros: simple. |
| 23 | Cons: nor propagated. |
| 24 | |
| 25 | I'd lean towards a new pref. |
| 26 | |
| 27 | Gianni suggested adding a new "Use GPU Full Speed" item to |
| 28 | the activity menu, but this isn't practical - among other things, |
| 29 | it would prevent the use of GPU prefs like |
| 30 | "don't use GPU when computer is in use". |
| 31 | |
| 32 | What are the semantics? |
| 33 | If the user changes the pref (or config option) |
| 34 | should running GPU jobs change their synch mode? |
| 35 | What about unstarted jobs? |
| 36 | |
| 37 | == How does it affect apps? == |
| 38 | |
| 39 | Should there be separate app versions for the 2 types of synch? |
| 40 | No; that would prevent users from changing mode mid-job. |
| 41 | Apps should be able to do either type of synch, based on a flag in APP_INIT_DATA. |
| 42 | Let's call such app versions '''synch-selectable'''. |
| 43 | |
| 44 | BOINC needs to know whether a given app version is synch-selectable. |
| 45 | We'll do this with an element in the app version's XML doc |
| 46 | (update_versions will have to be changed to support this). |
| 47 | |
| 48 | == How does it affect server scheduling? == |
| 49 | |
| 50 | What avg_ncpus does the scheduler report? |
| 51 | |
| 52 | What avg_ncpus does it use in accounting the CPU seconds for jobs sent? |
| 53 | |
| 54 | How is job completion time estimation impacted? |
| 55 | (potentially not at all - the system will adapt). |
| 56 | |
| 57 | == How does it affect client scheduling? == |
| 58 | |
| 59 | Let's assume that app_version.avg_ncpus is the non-busywait value (e.g. 0.1 or so). |
| 60 | |
| 61 | If the full-speed pref is set, |
| 62 | and the app version is synch-selectable, |
| 63 | then the client needs to set avg_ncpus to 1. |
| 64 | Otherwise we'll overcommit the CPUs. |
| 65 | (Note: we need to save the original avg_ncpus somewhere, |
| 66 | in case the user turns off the pref). |