Chromium Renderserver Overview

This page describes the software and hardware components involved in the Chromium Renderserver. For installation and configuration details see the Chromium Renderserver setup guide.

[XXX Insert CRRS Diagram here]

1. DMX X Server

DMX (Distributed Multi-head Xinerama) is a special X server used for consolidating a collection of workstation screens as an aggregate display. This allows a display wall to be constructed from a number of screens such that the wall appears as a single X desktop to application programs.

DMX is not a required component of Chromium Renderserver; it's only needed when a multi-screen display is involved. Without DMX, Chromium Renderserver can be used to remotely view/use a conventional single-screen desktop.

The DMX X server process can run on any host in the cluster. X rendering commands sent from the client application are propogated by the DMX X server to the back-end X servers. The DMX server can use the keyboard and mouse of any back-end display for input.

For an application to appear on the DMX display, it only has to use the appropriate X display name. This is typically hostname:1 where hostname is the name of the computer on which the Xdmx process is running.

For the Chromium Render Server project, the DMX server has been enhanced with input-only VNC ability. This means VNC clients can connect to the DMX server and sent mouse/keyboard events to it, but it cannot handle RFB update-request messages. This is all the functionality that's required by the VNC Proxy since the VNC Proxy will obtain RFB updates from the back-end X servers, not the DMX server.

In principle the DMX server could implement full VNC/RFB functionality. That is, when the VNC viewer asked the DMX/VNC extension for framebuffer updates the DMX server would retrieve the needed pixel data from the back-end servers. However, the burdon on the DMX server (and cluster network) would increase with each additional VNC viewer.

2. Backend X Servers

When using a DMX configuration, each of the individual back-end displays is controlled by a conventional X server. Each display also has hardware-accelerated OpenGL.

For the Chromium Render Server,the back-end X servers also have two particular X extensions: VNC and XClipList. The VNC extension allows VNC viewers to connect to the X server while the XClipList extension is used by the VNC SPU (described below).

3. Chromium

Chromium is used to run OpenGL applications on the DMX display wall. When not using DMX, Chromium is still used to send OpenGL renderings to the VNC Proxy and Viewer.

In particular, the application links with a special Chromium library which sends the application's OpenGL commands directly to the back-end displays. An alternative to Chromium is the GLX Proxy extension to DMX. The GLX Proxy is less-efficient, however, because each OpenGL rendering command must make two hops: from the application to the DMX server and from the DMX server to the back-end display(s).

For the Chromium Render Server project, Chromium is used as follows. Things work a bit differently depending on whether DMX is being used.

With DMX:

The application is linked with Chromium's libcrfaker.so library rather than the conventional libGL.so OpenGL library.
The crfaker library spawns a Chromium mothership process which describes the overall Chromium configuration. The crfaker library also loads a Tilesort SPU.
The Chromium mothership process remotely spawns crserver processes on each of the back-end DMX hosts.
The tilesort SPU processes the OpenGL commands issued by the application and sends them to the crservers. The Tilesort SPU uses a variety of techniques to minimize the amount of rendering commands sent over the network to the back-end hosts.
The tilesort SPU also communicates with the DMX server to determine the layout of the application's windows on the back-end displays. Whenever an application window is moved or resized the tilesort SPU must adjust itself so that rendering commands are routed correctly.
Each of the crservers loads a VNC SPU. Like the Render SPU, it renders the incoming OpenGL command stream into a window but it also acts as a VNC server. This is further described in the following section.

Without DMX:

The application is linked with Chromium's libcrfaker.so library rather than the conventional libGL.so OpenGL library.
The crfaker library spawns a Chromium mothership process which describes the overall Chromium configuration. A VNC SPU is loaded.
The VNC SPU used glReadPixels to read back the OpenGL rendering at the end of each frame. A second thread in the SPU sends the images to the VNC Proxy.

Note that after the system has been configured, none of this complexity is apparent to the end-user; OpenGL applications can be started in the usual manner, they appear on the display (or DMX display wall) and behave just as they do on a conventional workstation screen.

4. VNC SPU

The VNC SPU is a new component developed for the Chromium Render Server project. Like the Render SPU, it renders OpenGL commands into a window. Additionally, the VNC SPU is a VNC server. This allows VNC viewers to connect to it and view the OpenGL rendering in the SPU's window.

The VNC SPU uses OpenGL's glReadPixels command to quickly copy the image from the window to a buffer in main memory. This is done upon the SwapBuffers command or glFlush/glFinish when rendering to the front color buffer. The VNC server, running in a separate thread, accepts RFB update-request messages from the VNC Proxy and sends RFB update messages (image data) in return.

Incidentally, an ordinary VNC viewer may connect to the VNC SPU to view just the OpenGL rendering.

Ideally, there would be no need for the VNC SPU: the VNC extension to the back-end X servers would detect when the contents of OpenGL windows changed and send updated pixel data to the VNC clients (just like all other X windows). This doesn't work for two reasons:

OpenGL uses direct rendering to bypass the X server to achieve maximum performance. This means the X server does not know when the contents of an OpenGL window have changed. In fact, a VNC viewer connected to the screen will only see blank windows where OpenGL rendering should appear.
The VNC SPU can copy image data out of the window with glReadPixels much faster than the X server can copy data out of the framebuffer. Though with X server optimization this disadvantage could be mitigated.

5. VNC Proxy

The VNC Proxy is a new program developed for the Chromium Render Server project. It operates between the application workstation (or DMX display cluster) and some number of VNC viewers, acting as a VNC aggregator and reflector.

The back-side of the VNC Proxy connects to the X servers and VNC SPUs. The front-side of the VNC Proxy connects to some number of VNC viewers operated by the users.

The VNC Proxy works as follows:

The VNC Proxy is started with an X display name as a command line parameter. This names the desktop to be viewed with VNC.
The VNC Proxy checks if the display is a DMX server and if so, connects to the back-end DMX display and requests information about the back-end displays (hostnames, the screen sizes, their relative positions, etc).
For a DMX desktop, the VNC Proxy connects to each of the back-end X server via the VNC extension described in section 2. This is the means by which the VNC Proxy will get the non-OpenGL image data from the display wall.
The VNC Proxy tries to connect to any VNC SPUs currently running. This is how the VNC Proxy will obtain OpenGL-rendered imagery.
The VNC Proxy aggregates the image data obtained from the X VNC extension and VNC SPUs in a private, software-based framebuffer equal in size to the named desktop.
VNC viewers connect to the VNC Proxy as if it were any other VNC server. When the VNC viewers request framebuffer updates, they're replied to with image data from the private framebuffer. When using DMX, input events from the VNC viewers are propagated to the DMX X server.

Another approach to the problem of viewing a DMX display with a VNC viewer would be to write a special VNC viewer which directly connected to all the back-end hosts rather than a Proxy. There are several problems with that approach, however:

Specialized viewer: The advantage of the VNC Proxy is that any off-the-shelf VNC viewer can be used. There are VNC viewers for almost every desktop and hand-help operating system. Plus there are platform-independent Java viewers which run in web browsers. Requiring a special viewer would be very inconvenient.
Network security: If there are N back-end displays, there are 2 x N back-end connections to the VNC Proxy. But there is only one connection between the VNC Proxy and each viewer. If the VNC Proxy is hosted on the rendering cluster, only one connection must cross the network gateway/firewall to the outside world. If a special VNC viewer directly connected to the back-end displays, there would be 2 x N connections through the gateway/firewall to be concerned with.
Load balancing: If viewers directly connected to the back-end hosts, additional viewers would impose extra load on those hosts. With the VNC Proxy, the number of viewers doesn't directly effect the load on the back-end hosts. The VNC Proxy insulates the demands of serving many viewers from the rendering cluster.

6. VNC Viewer

Any VNC viewer may be used with the Chromium Render Server. Be aware that not all VNC viewers are created equally. The VNC/RFB protocol supports a variety of image encoding techniques and extensions which can effect the performance and, in some cases, the functionality of the viewer.

The VNC viewer from the XF4VNC project has been specially modified for the Render Server project to measure performance.

The VNC Proxy also supports a Java-based VNC Viewer that can be run inside any Java-capable web browser. See the VNC Proxy User Guide for details.