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…
Show HN: Attaching to a virtual GPU over TCP
81–90 of 117 posts
Re: Show HN: Attaching to a virtual GPU over TCP
#82Given the interest here we decided to open up T4 instances for free. Would love for y'all to try it and let us know your thoughts!
Re: Show HN: Attaching to a virtual GPU over TCP
#83For 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?
LD_PRELOAD trick allows you to intercept and virtualize calls to the CUDA runtime.
Re: Show HN: Attaching to a virtual GPU over TCP
#84Earlier 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 :)
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
#85Ah 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…
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
#86Does it work for gaming on windows ? or even linux ?
Re: Show HN: Attaching to a virtual GPU over TCP
#87Earlier 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
Re: Show HN: Attaching to a virtual GPU over TCP
#88Ah 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…
Re: Show HN: Attaching to a virtual GPU over TCP
#89Re: Show HN: Attaching to a virtual GPU over TCP
#90Earlier 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?