You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Tim Worcester <ti...@gmail.com> on 2020/05/21 18:05:21 UTC

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!

Re: Hardware Acceleration Support

Posted by Tim Worcester <ti...@gmail.com>.
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 <se...@gmail.com> 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 <video> 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 <mj...@apache.org> wrote:
> >
> > On Thu, May 21, 2020 at 1:39 PM Sean Reid <se...@gmail.com> wrote:
> >>
> >> On Thu, May 21, 2020 at 4:24 PM sciUser <sh...@securitycentric.net>
> 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-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
>
>

Re: Hardware Acceleration Support

Posted by Sean Reid <se...@gmail.com>.
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 <video> 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 <mj...@apache.org> wrote:
>
> On Thu, May 21, 2020 at 1:39 PM Sean Reid <se...@gmail.com> wrote:
>>
>> On Thu, May 21, 2020 at 4:24 PM sciUser <sh...@securitycentric.net> 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-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org


Re: Hardware Acceleration Support

Posted by Mike Jumper <mj...@apache.org>.
On Thu, May 21, 2020 at 1:39 PM Sean Reid <se...@gmail.com> wrote:

> On Thu, May 21, 2020 at 4:24 PM sciUser <sh...@securitycentric.net>
> 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

Posted by Sean Reid <se...@gmail.com>.
On Thu, May 21, 2020 at 4:24 PM sciUser <sh...@securitycentric.net> 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-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org


Re: Hardware Acceleration Support

Posted by sciUser <sh...@securitycentric.net>.
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-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org


Re: Hardware Acceleration Support

Posted by Nick Couchman <vn...@apache.org>.
On Thu, May 21, 2020 at 2:05 PM Tim Worcester <ti...@gmail.com>
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