@dotstdy @tauon @mntmn I think we may be talking past each other. I am not arguing for remote rendering (although I do something like this, but this is more compute than rendering), but my point is that GPU programming *is* programming a remote device because the PCI bus - although less than a network - is a bottleneck and this is why both X and Wayland a remote buffer management protocols and not fundamentally different in this respect.

@dotstdy @tauon @mntmn The command stream is streamed anyway (in some sense). I do not understand your comment about the data. You also want this to be in GPU memory at the time it is accessed. Of course, you do not want to serialize your data through a network protocol, but in X when rendering locally, this is also not done. The point is that you need a protocol for manipulating remote buffers without involving the CPU. This works with X and Wayland and is also what we do (manually) in compute

@dotstdy @tauon @mntmn Yes, this makes sense and I am not disagreeing with any of it. But my point is merely that a display protocol that treats the GPU as remote is not fundamentally flawed as some people claim, because the GPU *is* remote even when local. And I could imagine that for some applications such as CAD, remote rendering might still could make sense. We use remote GPU for real-time processing of imaging data, and the network adds negligible latency.

@dotstdy @tauon @mntmn We found it critically important to treat the GPU as "remote" in the sense that we keep all hot data on the GPU, keep the GPU processing pipelines full, and hide latency of data transfer for the GPU. I am sure it is similar for you. But I can see that in gaming you may want to render closer to the CPU than to the screen. But this does not seem to change the fact that GPU is "remote", or?

@dotstdy @tauon @mntmn So you do not keep your game data in GPU memory?

@dotstdy @tauon @mntmn I use GPUs for high-performance computing. So I think I know a little bit on how this works.

@dotstdy @tauon @mntmn I use GPUs for high-performance real-time imaging applications. So I think I know a little bit on how this works.

@dotstdy @tauon @mntmn But I think even for many 3D applications that render locally, a remote rendering protocol is actually the right thing, because for all intents and purposes a discrete GPU is *not* local to the CPU and whether you stream the commands via PCI or the network is not so different. In fact, Wayland is also a designed for remote rendering in this sense just in a much more limited way.

@dotstdy @tauon @mntmn This depends on where the strong GPU is, but as I said, pixel pushing should work also with X. I use medical image viewer over X, the image content updated very quickly. What is slow is the GTK part because it is implemented badly.

@tauon @mntmn @dotstdy Both could work just fine with X in theory. The GLX extension - a long time in the past - could do remote 3D rendering, but pixel shuffling over X could also work fine. X is a very generic and flexible remote buffer handling protocol. The issues with ssh -X are mostly latency related because toolkits (and blender if not using a standard one then has one builtin) use it synchronously instead of asynchronously.

@tauon @mntmn It could be though, if toolkits cared enough to use it efficiently, otherwise you could use something such as xpra which I guess is similar to waypipe. But that we are back to such solutions instead of having a proper remote protocol is a bit sad.