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

uhm, did you know that waypipe with ssh is fast enough to use blender remotely over wi-fi? what? this works much better/faster than x11 forwarding ever did

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

@uecker @tauon @mntmn for applications like blender there's neither a toolkit, nor any good way to handle forwarding that isn't streaming.

@dotstdy@mastodon.social @uecker@mastodon.social @mntmn@mastodon.social can't you just forward the opengl instructions? presumably the computer has a gpu too

@dotstdy@mastodon.social @uecker@mastodon.social @mntmn@mastodon.social actually then you'd run into the same problem sending the textures over the network too wouldn't you

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

@uecker @tauon @mntmn remote rendering for a program which is heavily reliant on the GPU like blender is the exact opposite of why you'd want remoting though. (Plus none of those virtualization things really work so well in the modern day, it's not gl1.1 anymore, the model just doesn't fit)

@uecker @tauon @mntmn remote rendering for a program which is heavily reliant on the GPU like blender is the exact opposite of why you'd want remoting though. (Plus none of those virtualization things really work so well in the modern day, it's not gl1.1 anymore, the model just doesn't fit)

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

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

@uecker @tauon @mntmn Unfortunately that's really not how the GPU works at all in the present day, it made more sense back in OpenGL 1.1 when there were pretty straightforward sets of "commands" and limited amounts of data passing between the GPU and the CPU. Nowadays with things like bindless textures and gpu-driven rendering, and compute, practically every draw call can access practically all the data on the GPU, and the CPU can write arbitrary data directly to GPU VRAM at any time.

@uecker @tauon @mntmn For very simple GPU programs you can make it work, but more advanced programs just do not work under a model with such restricted bandwidth between the GPU and the CPU. Plus, as was mentioned up-thread, you still need to somehow compress and decompress those textures online, which is itself a complex task. Plus you still need the GPU power on the thin client to render it. It's very much easier to render on the host, and then compress and transfer the whole framebuffer.

@uecker @tauon @mntmn For very simple GPU programs you can make it work, but more advanced programs just do not work under a model with such restricted bandwidth between the GPU and the CPU. Plus, as was mentioned up-thread, you still need to somehow compress and decompress those textures online, which is itself a complex task. Plus you still need the GPU power on the thin client to render it. It's very much easier to render on the host, and then compress and transfer the whole framebuffer.

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

@uecker @tauon @mntmn me too, i make aaa video games

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

@uecker @tauon @mntmn we keep gigabytes of constantly changing data in GPU memory. so yes, but unless you want to stream 10GB of data before you render your first frame, then no. (obviously blender is less extreme here, but cad applications still deal with tremendous amounts of geometry, to say nothing of the online interactive path tracing and whatnot)

@uecker @tauon @mntmn we keep gigabytes of constantly changing data in GPU memory. so yes, but unless you want to stream 10GB of data before you render your first frame, then no. (obviously blender is less extreme here, but cad applications still deal with tremendous amounts of geometry, to say nothing of the online interactive path tracing and whatnot)

@uecker @tauon @mntmn The PCIe bus lets us move hundreds of megabytes of data between VRAM and RAM every frame. And so we do that. Our engine also relies on CPU read-back of the downsampled depth buffer from the previous frame, so that's a non-starter, however that's not something you'd run into outside of games, probably.

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