<div dir="ltr"><div>Thanks, all.</div><div><br></div><div>I think that answers the question. Really, Wayland is not an appropriate place for proper multi-GPU processing (which would be invisible to an application). So, if it were to be done "the right way", it would be in the compositor, and the compositor needs better support from DRM and other underpinnings.</div><br>One thing that I was interested in was this kind of thing at the level of the driver. The only mention of it I could find on the entire Internet was an experiment that ATI had done called "Partial Surface Rendering". There's a video that talks about it for about 10 minutes and that's about all:<div><br><a href="https://www.youtube.com/watch?v=u4mOIn8jgp8#t=15m55s">https://www.youtube.com/watch?v=u4mOIn8jgp8#t=15m55s</a></div><div><br></div><div><br></div><div>If multi-GPU support happened inside of the driver, would this all be transparent to Wayland then? And would that solve the whole issue?</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 3:21 PM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 2 October 2014 23:13, Dave Airlie <span dir="ltr"><<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><span class="">On 1 October 2014 03:15, Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>> wrote:<br></span><div><div class="h5">> On 30 September 2014 16:44, Jasper St. Pierre <<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</a>> wrote:<br>>> It's a great question, with a complicated answer. Part of this is the<br>
>> fault of the DRM kernel interface, which is being improved. Part of it is<br>
>> the fault of GL/EGL, which really doesn't have proper multi-GPU support.<br><br>
</div></div></span><div><div class="h5">Also there is a good reason Windows doesn't work with multiple<br>
graphics cards anymore that aren't from the same vendor and in the<br>
same general class of chip.<br>
<br>
For running a wall of lots of monitors or you need multiple ATI or<br>
multiple NVIDIA cards, getting anything else to function in a rational<br>
manner isn't supported or at least wasn't last I look.<br>
<br>
Since you have a compositor running you no longer have the knowledge<br>
of on-screen clipping to say where to direct rendering,<br>
<br>
There is unfortunately no "nice" solution to this problem, under X or<br>
wayland, except making apps that are aware of the problem and use<br>
interface provided to solve it.<br>
<br>
You also have the optimus style solutions, which is run everything on<br>
one GPU and just use the other GPUs as slave outputs.<br></div></div></blockquote><div><br></div><div>Yeah, actually exploding them is a very difficult problem. Especially in a system like Wayland rather than X11, where we don't hand out global co-ordinates, so we can't just say 'this chunk is on this GPU, that chunk on that GPU, ...'. We'd need a way to explode the surfaces in such a way that you could atomically attach multiple buffers, plus compositor support for ensuring coherent presentation of all those buffers, and then try to keep the display controller side of things as tight as possible, which if you're doing media or moving anything around between outputs, really means cross-device genlock.</div><div><br></div><div>Long short short, there's nothing in Wayland that precludes it, but it really is the very very least of your problems.</div><div><br></div><div>Cheers,</div><div>Dan</div></div></div></div></blockquote></div></div></div></div>