Live data from Hacker News

Show HN: Attaching to a virtual GPU over TCP

thundercompute.com

81–90 of 117 posts

Re: Show HN: Attaching to a virtual GPU over TCP

#81

Ah this is quite interesting! I had a usecase where I needed a GPU-over-IP but only for transcoding videos. I had a not-so-powerful AMD GPU in my homelab server that somehow kept crashing the kernel any time I tried to encode videos with it and also an NVIDIA RTX 3080 in a gaming machine. So I wrote https://github.com/steelbrain/ffmpeg-over-ip and had the server running in the windows machine and the client in the me…

[dead]

Re: Show HN: Attaching to a virtual GPU over TCP

#83

For anyone curious about how this actually works, it looks like a library is injected into your process to hook these functions [1] in order to forward them to the service. [1] https://pastebin.com/raw/kCYmXr5A

How did you figure out these were hooked? I'm assuming some flag that tells ld/ldd to tell you when some symbol is rebound? Also I thought a symbol has to be a weak symbol to be rebound and assuming nvidia doesn't expose weak symbols (why would they) the implication is that their thing is basically LD_PRELOADed?

Yes. While I don't know what they do internally, API remoting has been used for GPUs since at least rCUDA - that's over 10 years ago.

LD_PRELOAD trick allows you to intercept and virtualize calls to the CUDA runtime.

Re: Show HN: Attaching to a virtual GPU over TCP

#84
post #42
post #38

Earlier quoted context omitted.

Blender can run on Linux…

Oh nice, I didn't know that! In that case it might work, you could try running `tnr run ./blender` (replace the ./blender with how you'd launch blender from the CLI) to see what happens. We haven't tested it so I can't make promises about performance or stability :)

Disclaimer: I only have a passing familiarity with Blender, so I might be wrong on some counts.

I think you'd want to run the blender GUI locally and only call out to a headless rendering server ("render farm") that uses your service under the hood to get the actual render.

This separation is already something blender supports, and you could for instance use Blender on Windows despite your render farm using Linux servers.

Cloud rendering is adjacent to what you're offering, and it should be trivial for you to expand into that space by just figuring out the setup and preparing a guide for users wishing to do that with your service.

Re: Show HN: Attaching to a virtual GPU over TCP

#85
post #44

Ah this is quite interesting! I had a usecase where I needed a GPU-over-IP but only for transcoding videos. I had a not-so-powerful AMD GPU in my homelab server that somehow kept crashing the kernel any time I tried to encode videos with it and also an NVIDIA RTX 3080 in a gaming machine. So I wrote https://github.com/steelbrain/ffmpeg-over-ip and had the server running in the windows machine and the client in the me…

This is more or less what I was hoping for when I saw the submission title. Was disappointed to see that the submission wasn't actually a useful generic tool but instead a paid cloud service. Of course the real content is in the comments. As an aside, are there any uses for GPU-over-network other than video encoding? The increased latency seems like it would prohibit anything machine learning related or graphics inte…

I mean, anything you use a GPU/TPU for could benefit.

IPMI and such could use it. Like, for example, Proxmox could use it. Machine learning tasks (like Frigate) and hashcat could also use such. All in theory, of course. Many tasks use VNC right now, or SPICE. The ability to extract your GPU in the Unix way over TCP/IP is powerful. Though Node.js would not be the way I'd want such to go.

Re: Show HN: Attaching to a virtual GPU over TCP

#86

Does it work for gaming on windows ? or even linux ?

You could use a remote streaming protocol, like Parsec, for that. You'd need your own cloud account and connect directly to a GPU-enabled cloud machine. Otherwise, it would work to let you game.

Re: Show HN: Attaching to a virtual GPU over TCP

#87
post #32
post #21

Earlier quoted context omitted.

We had a hell of a time dealing with the licensing issues and ultimately just gave up and give people whole GPUs. What are you doing to reset the GPU to clean state after a run? It's surprisingly complicated to do this securely (we're writing up a back-to-back sequence of audits we did with Atredis and Tetrel; should be publishing in a month or two).

We kill the process to reset the GPU. Since we only store GPU state that's the only clean up we need to do

Won’t the VRAM still contain old bits?

Re: Show HN: Attaching to a virtual GPU over TCP

#88
post #44

Ah this is quite interesting! I had a usecase where I needed a GPU-over-IP but only for transcoding videos. I had a not-so-powerful AMD GPU in my homelab server that somehow kept crashing the kernel any time I tried to encode videos with it and also an NVIDIA RTX 3080 in a gaming machine. So I wrote https://github.com/steelbrain/ffmpeg-over-ip and had the server running in the windows machine and the client in the me…

This is more or less what I was hoping for when I saw the submission title. Was disappointed to see that the submission wasn't actually a useful generic tool but instead a paid cloud service. Of course the real content is in the comments. As an aside, are there any uses for GPU-over-network other than video encoding? The increased latency seems like it would prohibit anything machine learning related or graphics inte…

How do you use it for video encoding/decoding? Won't the uncompressed video (input for encoding or output of decoding) be too large to transmit over network practically?

Re: Show HN: Attaching to a virtual GPU over TCP

#90
post #88
post #44

Earlier quoted context omitted.

This is more or less what I was hoping for when I saw the submission title. Was disappointed to see that the submission wasn't actually a useful generic tool but instead a paid cloud service. Of course the real content is in the comments. As an aside, are there any uses for GPU-over-network other than video encoding? The increased latency seems like it would prohibit anything machine learning related or graphics inte…

How do you use it for video encoding/decoding? Won't the uncompressed video (input for encoding or output of decoding) be too large to transmit over network practically?

Well, the ffmpeg-over-ip tool in the GP does it by just not sending uncompressed video. It's more of an ffmpeg server where the server is implicitly expected to have access to a GPU that the client doesn't have, and only compressed video is being sent back and forth in the form of video streams that would normally be the input and output of ffmpeg. It's not a generic GPU server that tries to push a whole PCI bus over the network, which I personally think is a bit of a fool's errand and doomed to never be particularly useful to existing generic workloads. It would work if you very carefully redesign the workload to not take advantage of a GPU's typical high bandwidth and low latency, but if you have to do that then what's the point of trying to abstract over the device layer? Better to work at a higher level of abstraction where you can optimize for your particular application, rather than a lower level that you can't possibly implement well and then have to completely redo the higher levels anyway to work with it.
Post reply on HN