[Spice-devel] Spice Protocol Missing Headers

[geoff at hostfission.com]

On 2017-10-13 20:05, Frediano Ziglio wrote:
>> 
>> > I tried a few years back (spice-protocol 0.12.10) to move these code
>> > generation scripts to spice-protocol, but this did not work out
>> > nicely so this was reverted.
>> 
>> I found this too, I opted to use the spice.proto file to write my own
>> header
>> with the basics that were required.
>> 
>> >
>> > I agree that having the initial link messages in spice/protocol.h, but
>> > not the rest of the protocol in spice-protocol is unexpected. For now,
>> > I
>> > would suggest that you copy this messages.h file as you suggested, even
>> > if that's suboptimal. I don't expect that file to change that often.
>> >
>> > Can you give more details about the project you are working on?
>> 
>> Sure :). I spend most of my time in a Linux environment for work but
>> enjoy the odd game, so I figured I would give a Windows VM a go with 
>> VGA
>> passthrough. It works a treat but the issue is getting a video feed 
>> back
>> to the host, the solutions that are available IMO are substandard
>> (ShadowPlay or Steam InHouse Streaming) as I want to have full control
>> over the host as well, not just in games.
>> 
>> These services compress to h264 and stream it over the network, where 
>> it
>> is decoded for display. Since this is all on the local host, I figured
>> all those overheads could be bypassed by writing a windows driver that
>> allows the host to share some memory mapped ram with the guest. Then 
>> on
>> the guest I wrote an application that uses NvFBC to capture raw frames
>> of the desktop and copy them into the shared memory segment.
>> 
>> This is why I needed a custom client, I am not using spice for the 
>> video
>> feed, it's just there for mouse and keyboard input. The end result is
>> outstanding, the latency is near zero and the video quality is 
>> lossless.
> 
> Maybe a silly question but if it's all local, don't you have a
> physical monitor connected? NcFBC means you passed an Nvidia card to
> the VM. Or basically you have 2 cards, one Nvidia and one Intel but
> you want the output on the Intel one as, for instance, you don't have
> a monitor attached to the Nvidia (this can happens on some laptops) ?

I do have a physical monitor connected, but the point is that I don't 
want to have it connected. This would also open doors for those with 
integrated graphic cards that have no outputs such as those you mention 
on laptops.

> 
> In theory you could use a QXL device for memory sharing, copying the
> output to its memory and send draw commands to get the output.
> Unfortunately NvFBC system memory API handle the system buffer so
> this means that you'll probably have 3 copy:
> - Nvidia GPU -> system (NvFBC)
> - system -> shared
> - shared -> host GPU
> But probably is not a problem for you (you possibly can avoid a
> copy using CUDA or GL NvFBC interface).

I am already doing three copies, but I believe I can remove one if I can 
get qemu to directly map a texture buffer into the Guest VM. This way it 
would be

nVidia GPU -> System (NvFBC) -> Host GPU texture.

I was unaware that it would be possible to map memory through QXL, I 
went the easiest route to test this proof of concept before heavily 
investing time into a more robust solution. I am new to working with 
qemu and windows drivers in general, so it has been a slow start, any 
suggestions/pointers would be very welcome.

-Geoff