Re: Hardware Acceleration Support
Thanks guys! I will start diving into code for this. Just wanted to make sure I wasn't missing some magic configuration option ;) On Thu, May 21, 2020 at 4:59 PM Sean Reid wrote: > Mike, > > I think we'd have to coordinate a little bit to get there. I have it > for guacenc, but I'm familiar enough with libavcodec and libavformat > at this point from the PRs I have worked that I think I could > reasonably work on a POC to get it working in guacd. > > In addition, I've spent some minor effort trying to produce valid > HTTP-DASH representations of videos so that it can be easily streamed > to a front end for playback using a simple tag. > > As far as legality, I'm obviously no lawyer, but if it helps, I tend > to favor libx264 which is GPL (and we'd be linking against it rather > than statically compiling it in). However, I'm pretty sure H.264 is > patent-encumbered, so I have no idea how that works when the code is > GPL'd. And I've played with VP8 support too, so there might be an > avenue to move forward there if necessary. > > > Sean > > On Thu, May 21, 2020 at 4:49 PM Mike Jumper wrote: > > > > On Thu, May 21, 2020 at 1:39 PM Sean Reid wrote: > >> > >> On Thu, May 21, 2020 at 4:24 PM sciUser > wrote: > >> > > >> > As long as you have a GPU assigned to the VM it will handle the > rendering, > >> > Guacamole is just the broker for the RDP protocol. > >> > >> The pixels that come from RDP or VNC may be compressed in some way, > >> but before guacd sends them out to the client, it still has to unpack > >> them and convert them to png, jpeg, webp (if it was compiled to > >> include webp) in the guacamole protocol. With this in mind, I'd be > >> interested in seeing guacd could scale better than it already does > >> with GPU-based image encoding. It's possible we could see more > >> connection to unique displays with GPU encoding. > >> > >> In addition, guecenc is an area I've toyed with adding GPU support to > >> personally since I've spent a lot of time adding H.264 support to > >> guacenc and modern GPUs almost certainly have H.264 hardware encoding > >> support. The issue I ran into was one of user interface: requiring a > >> user to know their set up well-enough to tell guacenc to use the nvenc > >> encoder seemed like a bad UI choice to me, and I had no good ideas for > >> how to automatically detect that support and use it. So I didn't push > >> it too much further. But if you have ideas, I'd love to see optional > >> GPU encoding support there! > > > > > > If you have something (or can have something) which could produce an > H.264 stream within guacd, I have some working POC code which decodes H.264 > streams received within the Guacamole client (streams sent via the "video" > instruction and subsequent blobs). The code leverages the "Broadway" H.264 > decoder. > > > > I think we'd need legal confirmation that including such a decoder and > encoder is OK, but overall definitely worth doing. It sounds like we may be > closer to having this than I thought. > > > > - Mike > > > > - > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > >
Re: Hardware Acceleration Support
On Thu, May 21, 2020 at 1:39 PM Sean Reid wrote: > On Thu, May 21, 2020 at 4:24 PM sciUser > wrote: > > > > As long as you have a GPU assigned to the VM it will handle the > rendering, > > Guacamole is just the broker for the RDP protocol. > > The pixels that come from RDP or VNC may be compressed in some way, > but before guacd sends them out to the client, it still has to unpack > them and convert them to png, jpeg, webp (if it was compiled to > include webp) in the guacamole protocol. With this in mind, I'd be > interested in seeing guacd could scale better than it already does > with GPU-based image encoding. It's possible we could see more > connection to unique displays with GPU encoding. > > In addition, guecenc is an area I've toyed with adding GPU support to > personally since I've spent a lot of time adding H.264 support to > guacenc and modern GPUs almost certainly have H.264 hardware encoding > support. The issue I ran into was one of user interface: requiring a > user to know their set up well-enough to tell guacenc to use the nvenc > encoder seemed like a bad UI choice to me, and I had no good ideas for > how to automatically detect that support and use it. So I didn't push > it too much further. But if you have ideas, I'd love to see optional > GPU encoding support there! If you have something (or *can *have something) which could produce an H.264 stream within guacd, I have some working POC code which decodes H.264 streams received within the Guacamole client (streams sent via the "video" instruction and subsequent blobs). The code leverages the "Broadway" H.264 decoder. I think we'd need legal confirmation that including such a decoder and encoder is OK, but overall definitely worth doing. It sounds like we may be closer to having this than I thought. - Mike
Re: Hardware Acceleration Support
On Thu, May 21, 2020 at 4:24 PM sciUser wrote: > > As long as you have a GPU assigned to the VM it will handle the rendering, > Guacamole is just the broker for the RDP protocol. The pixels that come from RDP or VNC may be compressed in some way, but before guacd sends them out to the client, it still has to unpack them and convert them to png, jpeg, webp (if it was compiled to include webp) in the guacamole protocol. With this in mind, I'd be interested in seeing guacd could scale better than it already does with GPU-based image encoding. It's possible we could see more connection to unique displays with GPU encoding. In addition, guecenc is an area I've toyed with adding GPU support to personally since I've spent a lot of time adding H.264 support to guacenc and modern GPUs almost certainly have H.264 hardware encoding support. The issue I ran into was one of user interface: requiring a user to know their set up well-enough to tell guacenc to use the nvenc encoder seemed like a bad UI choice to me, and I had no good ideas for how to automatically detect that support and use it. So I didn't push it too much further. But if you have ideas, I'd love to see optional GPU encoding support there! Sean - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: Hardware Acceleration Support
As long as you have a GPU assigned to the VM it will handle the rendering, Guacamole is just the broker for the RDP protocol. We run Blender and Unity on a Nvidia GPU for some labs, with a little fine tuning it will run as if it is on a physical system. - A Cybersecurity Enablement Company We don't just run you through the motions, Our labs teach you how to think! Known good Guacamole installations -- Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/ - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: Hardware Acceleration Support
On Thu, May 21, 2020 at 2:05 PM Tim Worcester wrote: > Greetings, > > I am toying around with the idea of gaming on my guacamole desktop. Is > there any additional configuration that I need to do in order to get > guacamole-server to use a GPU for the image encoding? Are there any other > parts of the application that would benefit the most from the GPU power? > > Write some code :-). There are currently no parts of the Guacamole code that take direct advantage of GPU offloading - this would have to be implemented. -Nick
Hardware Acceleration Support
Greetings, I am toying around with the idea of gaming on my guacamole desktop. Is there any additional configuration that I need to do in order to get guacamole-server to use a GPU for the image encoding? Are there any other parts of the application that would benefit the most from the GPU power? Thanks in advance!
