<div dir="ltr">I'm rebuilding <a href="http://ivs.research.mtu.edu">ivs.research.mtu.edu</a>, 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. </div><div class="gmail_extra"> <div class="gmail_quote">On Mon, May 15, 2017 at 4:22 PM, Adam Jackson <<a href="mailto:ajax@nwnk.net" target="_blank">ajax@nwnk.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 </blockquote></div> </div>