Exciting. But would definitely like to see a self hosted option.
Show HN: Attaching to a virtual GPU over TCP
111–117 of 117 posts
Re: Show HN: Attaching to a virtual GPU over TCP
#112In 2008, I had a powerful server with XEON CPU, but the motherboard had no slots for a graphics card. I also had a computer with a powerful graphics card but a weak Core 2 Duo. I had the idea of passing the graphics card over the network using Linux drivers. This concept has now been realized in this project. Good job!
Re: Show HN: Attaching to a virtual GPU over TCP
#113This is interesting, but I'm more interested in self-hosting. I already have a lot of GPUs (some running some not.) Does this have a self-hosting option so I can use the GPUs I already have?
You can rent out your GPUs in the cloud with services like Akash Network and rent GPUs at thundercompute.com.. manager's path, almost like self-hosting :)
Re: Show HN: Attaching to a virtual GPU over TCP
#114What makes me sad is that the original sgi engineers who developed glx were very careful to use x11 mechanisms for the gpu transport, so it was fairly trivial to send the gl stream over the network to render on your graphics card. "run on the supercomputer down the hall, render on your workstation". More recent driver development has not shown such care and this is usually no longer possible.
I am not sure how useful it was in reality(usually if you had a nice graphics card you also had a nice cpu) but I had fun playing around with it. There was something fascinating about getting accelerated graphics on a program running in the machine room. I was able to get glquake running like this once.
Re: Show HN: Attaching to a virtual GPU over TCP
#115Earlier 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…
I am increasingly growing tired of these "cloud" services, paid or not. :/
I agree. Paying by the month for the rest of your life or they cut you off is not something I am a fan of. I feel sorry for people too young to remember that you could actually buy an app, get free bug updates and get a discount if they made some big changes on a new version that you might (or might not) want. But it was up to you when and where you ran it and it was yours forever. I have heard the arguments for why people enjoy this monthly subscription model, but my counter argument is that people did just fine before without them, so what is so different now? And I mean, in general, not that you need to use a GPU for 1 hour but don't want to buy one. I mean, for example, how Adobe products run on your computer but you rent them forever.
Re: Show HN: Attaching to a virtual GPU over TCP
#116I’m more interested in using tools like hashcat, any benchmark on these? As the docs link returns error.
We haven't tested it with hashcat yet but plan on doing so. If you get to it before us please let us know how it works!
Re: Show HN: Attaching to a virtual GPU over TCP
#117This is interesting, but I'm more interested in self-hosting. I already have a lot of GPUs (some running some not.) Does this have a self-hosting option so I can use the GPUs I already have?
If you want a PyTorch-like experience on your own GPUs (either static or cloud), see https://github.com/run-house/runhouse