speeding up distributed multihead (xdmx)

[Joshua Marshall]

I'm rebuilding ivs.research.mtu.edu, which serves at a 4 by 6 display wall
of 1080p monitors.  The cluster is made of 1 master node, and 8 slave nodes
with each slave node driving 3 monitors (with twinview, no voodoo magic
there).  Each slave node has a high end sandy bridge era CPU, 32GB, and 2
GTX 680's.  They are all interconnected by a private infiniband and
ethernet network.  I've been charged with rebuilding it and basing it off
of RHEL 7.3.  Right now, I'm still looking into if the more limited, but up
to date and known to scale support of DisplayCluster should be used, or
figuring out something with Xdmx which has better feature support and a
more mature environment.

On Mon, May 15, 2017 at 4:22 PM, Adam Jackson <ajax at nwnk.net> wrote:

> On Sat, 2017-05-13 at 22:27 -0400, Joshua Marshall wrote:
>
> > This summer I've been charged with updating my university's display
> > wall.  It looks like the software features of X11 eclipse those of
> > DisplayCluster, but in speaking with the DisplayCluster author, it
> > _actually works_.  In particular, the performance over 16 screens was
> > wholly unacceptable and traced it to a part of the server which
> > serializes a nondescript something.
> >
> > Now, does anybody know what he is referring to, if the performance
> > issues persist, and how hard it might be to fix them?
>
> I looked up the DisplayCluster white paper, and while it does say that
> dmx doesn't scale beyond 16 tiles that's perhaps an unwarranted
> conclusion. I suspect what it refers to is that the stock X server
> source has an internal limitation of 16 screens. So yeah, performance
> beyond 16 tiles is going to be unacceptable, because it's zero ;)
>
> That's literally just a #define controlling the size of a few arrays
> though, you can change MAXSCREENS to whatever you want when you build.
> Alternatively, subdivide: one Xdmx frontend talking to four Xdmx
> middle-ends each talking to 16 tiles, for example.
>
> There could certainly be performance problems beyond that; more details
> would be helpful. Xdmx definitely has other limitations that might make
> it unsuitable for your use (old OpenGL support, 32 kilopixel coordinate
> limit, no compressed image transfer) so I don't want to oversell it,
> but if you do encounter issues please let us know so we can determine
> whether they're fixable.
>
> - ajax
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170516/cd5609f3/attachment.html>