Just making sure I understand this correctly, the guest GPU renders into its framebuffer which is then copied over PCIe into system memory and then into the host GPU?
So 1920*1080 * 60 fps * 32 bpp equals just under 4GB/s ((1920*1080*60*32 )/ (1024^2))
Unless I have done my math wrong that’s some serious bus saturation, this sounds incredibly expensive to do so what did I miss?
Not multiplied by 32, that’s 32-bits, aka 4 bytes.
Ah there we go, thats a lot better
AMD Users, the NPT patch has made it into Linux 4.15!
Is the windows resizable? If so, does it get up- or downsampled if you change its size?
Yes and it gets resampled, default is just pixel halving or doubling, but mipmaps can be turned on which generates a nicely scaled window. See my original screenshots up top 
The guest is running 1920x1200
Those that care can actually open that image up full size and sneak a peek at the client (host) code.
That’s cool, just like I would want it to work
@wendell I spoke with one of the engineers at VMWare about seamless mode and the summary was based on their analytics nearly nobody uses it so it isn’t worth investing into at all since it is relatively complex to develop and support.
Well good news, I believe we can do this too in time (version 2.0 perhaps). Once the source is out there it will open it up for everyone to hack in their favorite features, I would expect development progress to increase exponentially.
Once the source is out there it will open it up for everyone to hack in their favorite features
With bated breath I wait…
Oh yeah, the anticipation for that is going to be killer 
@gnif I chucked 50 upside-down Australian dollarydoos your way in the hopes it helps you get to a 1.0 release. Will probably convert into fuck all, but money where your mouth is and all that. I hope you reach your goal mate 
Thank you kindly! It’s worth more than you think , I am Aussie! 
Hold the phone - so @Lyynx92 here is saying that the GPU ‘pass through’ can be done over a 10Gb/s Ethernet link?
// mind blown // 
No, he is stating that it can be done using the mellanox connect-x 2 fiber interface cards using RDMA.
Your patch is in this commit from Linus,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7753ea09640807104c8e353f6d5dc47ee55307cf
I haven’t contributed to kernel dev before (I’d like to pick this up in future… it’s an area of interest) but it’s surprising (to me at least) that your original commit isn’t merged in with author credit going to you? Seems like a squash/rebase on his end… I suppose this is “normal”?
I didn’t author the patch, that was Paolo Bonzini from Red Hat. I found the root cause and a very hacky fix for the problem.
Here is the merged patch from that set, credit has been attributed:
I’m speechless, so the only thing I can come up with is: Thank you!!!
Oh! Sorry, thanks for the clarification…
Here’s a favour, if/when you have time. I’d appreciate a ‘newbies’ guide on how to contribute to kernel dev - not so much on ‘how to code’ but rather, the workflow, etiquette, how NOT to piss Linus off.
I can reflog with the best of 'em, so that’s not a pain point (personally for me) but, given we like to spread-knowledge here aimed at all levels, if you could post this thread taking a ‘wider’ audience into account, and maybe structuring it as such, that would be epic.
Also, your workflow on how you manage recompiling various kernel versions, and staying organised would be helpful too. I’d imagine that you have to run through the usual rigamarole of -
dracut magic in Fedora) (if needed)I has been a long time since I’ve gotten into this side of things…