Thanks, Thunderbird and Aaron.
I'd forgotten about possibility of using Mesa and that might be quite a good approach for developing the work. I would be really be trying eventually to exploit hardware acceleration if I can though. Using Mesa for now is something I'll definitely try.
I've experimented with the single X server / multiple X screens and this nearly does what I'm hoping for. I've allowed a gap between the screens (http://gentoo-wiki.com/HOWTO_Dual_Mo...Using_Xinerama
) and thereby locked the mouse to the first X screen so that the user is not really aware of the existence of the second X screen that is used for the renderer server.
The remaining problem is how to configure the system so that users can locally log on/off the machine without affecting the renderer.
If I write a normal daemon (that uses no GLX resources), I can start this, leave it running, and users logging on have no effect.
Would you be able to advise me on the best approach to writing a similar daemon, but one which does need GLX reources? This is a bit more general a question, but given the trend towards GPGPU programming, one that a number of people may have an interest in.
I've used graphical login:
id:5:initdefault: (in inittab)
From inspecting Xorg.0.log, it appears that upon a user closing a session and another user logging in, the X server is not restarted, but the NV-GLX module is reloaded (have I interpreted this correctly?)
If this is the case, would there be hooks that I could use to detect when the GLX module is about to become unavailable; and, similarly, to detect when it is again available? Or, with the present X architecture, do I have to leave myself permanently logged in, if I wish to have access to GLX computation?