Either approach is possible.

I'm doing much the same using Einstein's intel_gpu application using the HD 4000 / 4600 GPU built into various generations of i5 / i7 processors - that's a slightly different question, but it generalises to the discrete AMD GPU too.

If your AMD application runs at realtime priority without any unwanted side effects - neither slowing down the pure CPU applications too much by depriving them of resources, nor making the computer's video display jittery or slow to update - then you can lock each succeeding instance of the application to realtime priority by using a program called Process Lasso - the free edition is more than adequate for this task. The user interface is a little daunting at first, but basically you can -

- find a running example of the process in the process list
- right-click on the current priority class
- choose 'priority class --> Always' from the menu

And that's it. The program will look after itself from there on, with occasional updates and reminders for a few seconds at startup that donations would be welcome - as nag screens go, it's very polite and non-intrusive.

The alternative approach of 'freeing a CPU core' is often advocated, but from your description it sounds to be more drastic than you need. But if you want: BOINC can be instructed to "Use at most 75% of the CPUs" (i.e. three out of four) through your computing preferences - either through a project web site, or locally through the BOINC Manager Advanced View.

That will apply for all the projects you're attached to. You may find that Einstein responds best to the Process Lasso approach, SETI to 'Use at most 75% CPUs', and MilkyWay needs no tweaking at all - or some other combination. If you find that just one of your projects requires a completely free core, you can set that up using the Application configuration tool. That's a little more complicated, and I'd suggest you try the other two approaches first. If you need to use an app_config.xml, it might be best to ask on the message boards specific to the project you want to use it for.

Do know that all GPU applications need CPU time. The application that does the calculations on the GPU runs on the CPU, and only sends data to the GPU that it can do the calculations on.

On some projects, including Einstein, the Fast Fourier transform algorithm can only be accurately calculated on the CPU. So for each task the FFT runs on the CPU, while the 'space-data' is sent to the GPU.

As for running processes in realtime, it's not something you'd want to do as it may slow your computer down so much that you can't do anything on it anymore. At this priority the process runs at a higher priority than your mouse, your keyboard and your disk cache. This means that anything you will try to do to stop the process in a case of emergency will be ignored, or get through extremely slowly.

If you're worried you'll lose out on credits by telling BOINC to use one less CPU core, do know that any GPU can always out-perform any CPU, and thus make up for that with ease.

---

But also be aware that modern multi-tasking operating systems, running on modern multi-core CPUs, are designed to cope with many more active processes than there are CPUs. I'm typing this on a 4-core i5, with somewhere around 95-98 processes active (including 13 browser tabs).

One of the active processes is Process Lasso: another is an Einstein intel_gpu task held at real-time priority. I'm not noticing any problematic side-effects from that combination, although my display screen is being drawn by an NVidia GPU running SETI tasks at a mere 'above normal' priority.

So I'd say, from personal observation, that it's worth a try, though I completely accept that users should proceed carefully and thoughtfully, and avoid overloading their own hardware: I wouldn't even thinking about running realtime on a single-core computer, or four realtime tasks at once on this quadcore.