uhm, did you know that waypipe with ssh is fast enough to use blender remotely over wi-fi?

@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 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

@uecker @tauon @mntmn I'm not sure I even understand what you're saying in that case, waypipe does just stream the rendered buffer from the host to a remote client. It just doesn't serialize and send the GPU commands required to render that buffer on the remote client. The latter is very hard, the former is very practical.

@dotstdy@mastodon.social @uecker@mastodon.social @mntmn@mastodon.social the latter is only hard because each protocol has to do it instead of having 1 specific protocol for it like 9p

@tauon @mntmn @uecker No that's my point, it's *extremely* hard!

@tauon @mntmn @uecker Let me put it this way, when I render frame 1 of a GPU program, in order to execute the GPU commands to produce that frame, I need to have the *entire up to date contents of vram* in the 'client' gpu's vram (or at least memory accessible to the 'client' gpu). That's really hard, and is bounded only by the GPU memory that the application wants to use. But using the 'server' gpu to render a frame, and sending it to the remote, is a bounded, and much smaller amount of work.

@tauon @mntmn @uecker Let me put it this way, when I render frame 1 of a GPU program, in order to execute the GPU commands to produce that frame, I need to have the *entire up to date contents of vram* in the 'client' gpu's vram (or at least memory accessible to the 'client' gpu). That's really hard, and is bounded only by the GPU memory that the application wants to use. But using the 'server' gpu to render a frame, and sending it to the remote, is a bounded, and much smaller amount of work.

@uecker @tauon @mntmn I'm not sure I even understand what you're saying in that case, waypipe does just stream the rendered buffer from the host to a remote client. It just doesn't serialize and send the GPU commands required to render that buffer on the remote client. The latter is very hard, the former is very practical.

@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 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.

@uecker @tauon @mntmn nitpick aside: The reason that these are remote buffer management protocols is actually subtly different from bandwidth concerns, it's more about queuing and throughput. the latency between the GPU and the CPU is actually pretty low, and the bandwidth quite high, however we deliberately introduce extra latency in order to allow the GPU to run out-of-lockstep from the CPU to increase throughput. It prevents us from starving the GPU, by ensuring a continuous stream of work.