On 18 March 2011 04:14, Trevour Crow <cro...@yahoo.com> wrote: >> From: Josh Leverette <coder...@gmail.com> >> Subject: Re: HPC (High Performance Compute) Architecture >> To: "jonsm...@gmail.com" <jonsm...@gmail.com> >> Cc: "wayland-devel@lists.freedesktop.org" >> <wayland-devel@lists.freedesktop.org> >> Date: Thursday, March 17, 2011, 9:13 PM >> http://www.onlive.com ? But yeah, I was >> wanting this to be user transparent for all applications, >> since there is no way we could modify proprietary >> applications that use a lot of processor real estate and >> this would be a one time deal, no need to do it on an app by >> app basis. But, I understand. > I'm actually working with Gallium to make this possible - after discovering > that indirect mode GLX was limited to OpenGL 1.4(or at least the Mesa/X.Org > stack is, which is all I care about), I decided to see if I couldn't use > the pipe/stack tracker architecture to transparently relay rendering > commands from one machine to another; I haven't quite started work on how > "netpipe" will connect to the remote state tracker, but I've started laying > down the pipe driver side and it seems possible. This means that, combined > with the remote Wayland GSoC project, what you're talking about should be > possible for any program that ultimately renders using Gallium.
It's generally possible. Gallium removes one obstacle - it provides a middleware that is the same regardless of the graphics that is used for rendering. You will not be able to move an application from a more powerful graphics to a graphics with substantially fewer features available but that's it, Intel, ATI, nVidia, VMWare, all should work if you limit the features the application can use to those of your least capable card. The other issue is texture upload. Often 3D (or OpenGL) applications use huge amounts of textures and require that these be uploaded to the card quickly. You can present an unified netpipe model where both the card memory and the system memory is presented as one huge netpipe device memory and cache as many textures as you can on the remote end but this won't help for more intensive applications that switch between parts of complex scene (and swap the textures and models accordingly) or things like MPlayer GL video output. Relying on a powerful CPU/GPU to compress the rendered graphics into a video stream might be a more general solution. It has the advantage of decoupling the rendering and display. When there is fast scene change you may get temporary compression artifacts in the video stream but the rendering is not affected, and applications with poor event loops that only check for input between rendering frames (most, unfortunately) remain responsive. It also blends naturally with Wayland protocol that only supports window pixmap updates. Thanks Michal _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel