Request for sponsered development...

[Christian Weiß]

With some detours I finally arrived here.

I have a need out of a commercial project that may lead into some extensions within AIGLX
and Mesa. I'm going to describe the problem and I'm open for whatever comes to
your mind, even alternative approaches. If we (from a technical perspective you folks)
come to the conclusion it's beneficial for either Mesa, AIGLX or both, I willing to
sponsor the development by fully agreeing to the license concepts of the relevant
projects.

Consider an installation of about ~600 low budget thin-clients (with almost no 3D support
from the graphics chip) running as X-Terminals. Those thin-client stations are serviced by
a host computer for 25-30 stations each. This infrastructure should be the basis of an
architectural/interior planning system with serious demands in terms of 3D rendering.
It's all clear that the client hardware will not be able to provide the power, so it
comes down to a server-based rendering approach. Therefore some of ATI's or
Nvidia's latest boards should be attached to the host computers forming a CUDA cluster
for their terminals. So, the question is: how to get the image to the client? And, even
not absolutely necessary, all this should be transparent to the application.

And that's the idea: the driver for the CUDA cluster comes from the vendor and should
be used without any change. As a post-processing step within the pipeline (probably a
specific fragment shader) compresses the content and writes it to an off-screen buffer
(FBO). Now "something" out of either Mesa or AIGLX should take the buffer and
transfers it by the way of the X-protocol to the X-Server (of the X-Terminal). At that end
of the protocol we need a small piece of code that decompresses the buffer and copies it
to the frame buffer of the relevant window. Ideally this will not place a burden on the
CPU but is done within the GPU of the X-Terminals hardware. Again, maybe, a simple
fragment shader which takes the compressed buffer as texture image. Even today's
lowest-end hardware should provide that feature. Guess that should be supported by an
GLX_extension from the underlying driver. To a certain extent, the latter stuff sounds
much like what AIGLX is doing for desktop feature acceleration.

What I'm not so sure is, if

1) AIGLX provides the proper extensions to the X-protocol and
2) if the X-protocol is at all optimized for the rather considerable load of that data at
high frame-rates.

Suggestions, even those which call me completely displaced here, are very welcome.

Cheers,


Christian.

[Jason D. Clinton]

On Mon, Mar 7, 2011 at 08:56, Christian Weiß <christian.weisz(a)spoc.at&gt;wrote:

>  Consider an installation of about ~600 low budget thin-clients (with
> almost
>  no 3D support from the graphics chip) running as X-Terminals. Those
>  thin-client stations are serviced by a host computer for 25-30 stations
>  each. This infrastructure should be the basis of an architectural/interior
>  planning system with serious demands in terms of 3D rendering. It's all
>  clear that the client hardware will not be able to provide the power, so it
>  comes down to a server-based rendering approach.
>  
While your willingness to fund this kind of development is laudable, this
sounds rather like an organization doing LTSP and grappling with the
widespread proliferation of compositing window managers. If that's the case,
you should probably reevaluate the current state of thin client hardware.
Four years ago, when I last did this work, thin clients with 512MB of RAM
and an 945 Intel graphics chip were widely available for under $300. I'm
sure that things have improved. Any modern Intel graphics chipset >965 is
more than enough to run a compositor and 512 MB is plenty of RAM for a
desktop shell. This is essentially what Dave Richards at City of Largo is
doing.

The best way to run things in this configuration is to make the thin clients
root from NFS root or run a Live-CD like image on them and then run a script
in rc.local which drops your own customized .desktop files in
~/.local/share/applications in the Live user's home directory. These
.desktop files Exec= lines are SSH w/ remote X11 forwarding back to your
application servers. For example: Exec="ssh $username@libreoffice-server -Y
/usr/bin/oowriter".

It does require a little bit of initial scripting and figuring out how to
handle user accounts is specific to your environment but it puts all that
computing power on the thin clients, including their 3D hardware, to use.
When I last did this, I used ~/.local/share/autostart shell script to launch
a username and password prompt after the desktop was up to mount directories
and make the SSH w/ username links proper.

The other way to go about it is to get thin clients with 2GB of RAM and no
harddisk and just boot NFS root and run them as full-blown disk-less
workstations. Then all you need is a big file server. And less bandwidth
than LTSP requires (which is a huge plus.)

[Peter Robinson]

On Tue, Mar 8, 2011 at 3:55 PM, Jason D. Clinton <me(a)jasonclinton.com&gt; wrote:
>  On Mon, Mar 7, 2011 at 08:56, Christian Weiß
> <christian.weisz(a)spoc.at&gt;
>  wrote:
> >
> > Consider an installation of about ~600 low budget thin-clients (with
> > almost no 3D support from the graphics chip) running as X-Terminals. Those
> > thin-client stations are serviced by a host computer for 25-30 stations
> > each. This infrastructure should be the basis of an architectural/interior
> > planning system with serious demands in terms of 3D rendering. It's all
> > clear that the client hardware will not be able to provide the power, so it
> > comes down to a server-based rendering approach.
>
>  While your willingness to fund this kind of development is laudable, this
>  sounds rather like an organization doing LTSP and grappling with the
>  widespread proliferation of compositing window managers. If that's the case,
>  you should probably reevaluate the current state of thin client hardware.
>  Four years ago, when I last did this work, thin clients with 512MB of RAM
>  and an 945 Intel graphics chip were widely available for under $300. I'm
>  sure that things have improved. Any modern Intel graphics chipset >965 is
>  more than enough to run a compositor and 512 MB is plenty of RAM for a
>  desktop shell. This is essentially what Dave Richards at City of Largo is
>  doing.
>
>  The best way to run things in this configuration is to make the thin clients
>  root from NFS root or run a Live-CD like image on them and then run a script
>  in rc.local which drops your own customized .desktop files in
>  ~/.local/share/applications in the Live user's home directory. These
>  .desktop files Exec= lines are SSH w/ remote X11 forwarding back to your
>  application servers. For example: Exec="ssh $username@libreoffice-server -Y
>  /usr/bin/oowriter".
>
>  It does require a little bit of initial scripting and figuring out how to
>  handle user accounts is specific to your environment but it puts all that
>  computing power on the thin clients, including their 3D hardware, to use.
>  When I last did this, I used ~/.local/share/autostart shell script to launch
>  a username and password prompt after the desktop was up to mount directories
>  and make the SSH w/ username links proper.
>
>  The other way to go about it is to get thin clients with 2GB of RAM and no
>  harddisk and just boot NFS root and run them as full-blown disk-less
>  workstations. Then all you need is a big file server. And less bandwidth
>  than LTSP requires (which is a huge plus.) 
The biggest issue I see in that is that most thin style corp
deployments now days are moving towards (or at least looking closely
at) a VDI style deployment and most of those techs don't support 3D
either.

Peter

[Adam Jackson]

On 3/8/11 8:23 PM, Peter Robinson wrote:

>  The biggest issue I see in that is that most thin style corp
>  deployments now days are moving towards (or at least looking closely
>  at) a VDI style deployment and most of those techs don't support 3D
>  either. 
 From a (very) cursory look at Windows 7, they appear to do Aero 
remoting by drawing the window itself on the machine running the app, 
and then compositing windows onto the display wherever the compositor 
happens to be running.  Which is a pretty reasonable split; trying to 
remote all 3D rendering to the viewer can pretty easily swamp your 
bandwidth.

The problem that then creates in a VDI kind of world is that the machine 
all your guests are running on now has to run a 3D renderer.  I'm 
currently proof-of-concepting getting gnome-shell running with the 
software renderer, which would mean you could run it in kvm/vbox/etc, 
albeit with some CPU hit.  After that if you want guest density you need 
to figure out a way to offload 3D rendering to the host's GPU. 
Thankfully, given how DRI2 and KMS work, I think that's mostly a matter 
of passing the right ioctls through to the host rather than trying to do 
PCI passthrough.  All quite doable, just a lot of typing.

Of course, I also expected gnome-shell on llvmpipe to be a one day hack, 
and it's turned into more like two weeks, so maybe I'm being optimistic 
about the complexity.

- ajax