Lucie / minuteuhm, 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
i literally just did: `waypipe ssh minute@minute-i9 Downloads/blender-5.0.1-linux-x64/blender`
crypticcelery 🔜 EH23@mntmn oooh, that sounds very cool, need to try that sometime.
momo@mntmn 1st: very cool, that it seems to work so flawlessly. 2nd: I am curious: Why do you use a binary that you downloaded and not install blender on that system?
@momo ah, that's because debian's blender build has severe limitations, like no vulkan support and no wayland support
Tammi 𝆮 𓃠
Kate
Carlos Solís
Mae
grimmware
Nic Roland 
@mntmn now I need to update some files under ~/.local/share/applications so it does this under the hood when I open an app from the launcher.
It means some apps will only be able to be run from my home LAN (which is fine for me) but it also extends the life of my laptop (which is 11 years old already) if I can run compute heavy stuff on a local server
S T E L L A R 
@mntmn huh??? 
🌸 lily 🏳️⚧️ 
θΔ ⋐ & ∞this works much better/faster than x11 forwarding ever didi think this is cause waypipe uses h264 whereas x11 forwarding forwards the draw instructions which in the modern day is just "draw this 4k 32-bit colour pixmap" which isn't very efficient over the network
Martin Uecker
Josh Simmons@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.
@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 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.
@uecker @tauon @mntmn But like I hinted at before, there's also just issues like applications which just map all the GPU memory into the CPU address space and write it whenever they like (with their own internal synchronization of course). That's *really* hard to deal with, even for tools which trace GPU commands straight to disk. Doing it transparently over the internet is really really really hard.
@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?
@uecker @tauon @mntmn Similar, but likely at a narrower scale of latency tolerance. The issue is just the bandwidth v.s. the size of the working set, the GPU is remote (well, unless it's integrated) but PCIe 4 bandwidth is ~300 times greater than you get with a dedicated gigabit link. and vaguely ~15000 times greater than what you might have used to stream a compressed video.
@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.
@uecker @tauon @mntmn The reason it's flawed imo is that while it will work fine in restricted situations, it won't work in many others. Comparatively, streaming the output always works (modulo latency and quality), and you have a nice dial to adjust how bandwidth and CPU heavy you want to be (and thus latency and quality). If you stream the command stream you *must* stream all the data before rendering a frame, and you likely need to stream some of it without any lossy compression at all.
@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
Joakim Fors
trademark@tauon @mntmn the problem is that most programs issue too many synchronous calls, that is, they wait until the x server responds before they will send the next request so latency is killing them. I believe it doesn't need to be like this, but if programs haven't been fixed by now they are unlikely to ever be.
AndiS 🌞🍷🇪🇺I did not know that but it sounds awesome!
rick@mntmn ohh didn't know there is a new way for xforwarding. i always read that vnc is the new equivalent for that.. but vnc is also pain..
i currently use pikvm (which i already had for my homelab) with my old workstation in my server rack for forward desktop to my pocket, if i need more processing power or newer opengl stuff ^^
i currently use pikvm (which i already had for my homelab) with my old workstation in my server rack for forward desktop to my pocket, if i need more processing power or newer opengl stuff ^^
Saphira Lohikäärmekettunen 
poleguy looking for lost tools@rick @mntmn my department at work has been using x2go for years rather than vnc. For those who have never tried it, it is very nice for several reasons: it can be installed with no additional configuration and no daemon. It uses ssh for auth and transport so needs no extra ports opened or local port redirects or extra passwords set. It forwards audio without extra effort.
But It has trouble with Firefox on the latest Ubuntu due to snap and cgroups. The developers all point fingers and wontfix.
Will T@wjt ah. battery status is currently not wired up
kianryan ☑️🐙🏳️🌈@mntmn
Okay, I'm curious.
This has been one of my last X11 grumps.
Of course, I've not used X11 forwarding since university, but it's still a grump.
Okay, I'm curious.
This has been one of my last X11 grumps.
Of course, I've not used X11 forwarding since university, but it's still a grump.
@kianryan not needed because you can _also_ just use x11 forwarding on wayland, because of xwayland
Sir GarbagetruckYes. And the minute I found that out via experimentation I started building some additional machines to test things with, as "use a container" no longer is neccesary when spinning up a VM and running a test is much more comfortable and leaves things in a much cleaner state.
also I dislike containers (:
waypipe is excellent.
niconiconi@mntmn If one is stuck on X11, one can still do 3D forwarding with VirtualGL. Still maintained today. It replaces the GL libraries with a shim to send pixmaps over the network. The window activities and mouse clicks are still in X11.
Felicitas Pojtinger 🌅@mntmn Waypipe is such a cool tool. I use it to forward windows from a VM to my host and it's genuinely indistinguishable from a native app ...
@mntmn I’ve played one of the later Tomb Raiders, BAR and XPlane over waypipe over wifi
Brick Duck