The Virtual KMS Module Has Begun Progressing As Part Of GSoC 2018

[phoronix]

Phoronix: The Virtual KMS Module Has Begun Progressing As Part Of GSoC 2018

In addition to the Vulkan Virgl project another one of the interesting projects for Google Summer of Code 2018 is the development of VKMS, a Virtual KMS DRM driver...

http://www.phoronix.com/scan.php?page=news_item&px=VKMS-Virtual-KMS-Progress-1

[boxie]

sounds like something that could be awesome for a remote workstation

[timofonic]

Would this make MoSH, SSH and conventional remote desktop obsolete? I hope so

[nanonyme]

Would this make MoSH, SSH and conventional remote desktop obsolete? I hope so

I doubt SSH-style things will ever go obsolete. It's just so convenient to have authentication and secure tunnel be in one implementation. Also vast amount of firewalls special-case SSH port making it nigh impossible for anything else to gain sufficient traction. Heck, mosh also uses SSH to authenticate the initial connections because it's just so good

[arbition]

This was reported some time ago https://www.phoronix.com/scan.php?pa...irtual-Display so is this new GSoC project what is needed to get this actually usable? I have seen virtually no references to this AMD feature outside of that article.

[starshipeleven]

Would this make MoSH, SSH and conventional remote desktop obsolete? I hope so

I don't see why it would have any bearing with ssh, as if I just need a text console what is the GPU for?

And it isn't remote desktop by itself, but will surely be useful in such setups.

[oiaohm]

This was reported some time ago https://www.phoronix.com/scan.php?pa...irtual-Display so is this new GSoC project what is needed to get this actually usable? I have seen virtually no references to this AMD feature outside of that article.

There are a few differences. This virtual KMS module is not feature of an individual graphics driver. The AMDGPU virtual display is only a feature of the amdgpu driver.

https://devblogs.nvidia.com/egl-eye-opengl-visualization-without-x-server/

Nvidia, AMD and Intel support EGL support headless modes this at times requires a virtual display. Issue here is you would have to support each one unique processing. So that past amdgpu one is to support a EGL feature not be a generic.

You can look at the virtual KMS module as doing virtual displays in a generic way and allowing usage of standard KMS syscalls to control a virtual display instead of EGL or other special options. With prime support https://wiki.archlinux.org/index.php/PRIME for laptops you really only need to be able to provide a buffer somewhere for the graphics card to place the output in a straight up screen capture setup.

I would say the new virtual KMS module is required to make it practical. I also see KMS module as only the starting point.

Please note fully functional LInux KMS for PRIME under Linux supports "Damage Rectangle Interface". VNC for compression is only interested in the "Damage Rectangle areas". Damage Rectangle is the areas that have changed since last frame to reduce memory transfers. VNC is a good match for what is provided at the KMS layer inside Linux. PCoIP without the frame buffer object optimisations is also a good match at the KMS level.

Frame Buffers optimisations would mean getting into the DRM layer and Nvidia custom stuff to know what buffer that is being displayed on screen has changed and if this change is that the buffer has in fact been altered or has just been switched into view. If just switched into view and its already been sent across reuse what has been sent across is possible. This would be vmware used remote desktop compression PCoIP optimised. This will be a more complex problem. You really need virtual KMS before you would attempt this in kernel mode and it requires the ability to request what buffer/handle this damaged rectangle comes from. So in theory implementable from the virtual KMS module by having way to request more information about the "damaged rectangle" from the DRM layer. Of course a laptop using a gpu to put output on a different gpu does not require this feature. So this would be modify the DRM layer as well. Sanity says if you can work in 1 layer at a time you do so you don't end attempting to hurd more cats than you need to.

Windows based optimisation latest RDP uses means the compositor under wayland or x11. If this in fact provides any advantages over the Frame buffers optimisation is debatable and it is in theory possible to implement RDP down a layer.

Please note KMS using prime and KMS/DRM using prime(for frame buffer optimisations) would both be able to be done almost invisible to the wayland compositor or the X11 server. So not require per compositor support for remote desktop support. This also means security differences as well. The process providing the graphics over network could in fact been running at a completely different and less permissions than the user.

The reality is remote desktop technologies can be implemented at different layers in the stack. Some like VNC can be implemented quite deep as all it requirements are ticked off at the KMS layer. Some like PCoiP can also be implemented quite deep with some loss in efficiency.

I pure see this as first step. This was also one of the questions when doing wayland was if wayland really did need remote desktop support or if remote desktop support should be done in the kernel KMS/DRM layers using a protocol independent wayland.

[AndyChow]

Things with virtual GPU technology seem to finally be evolving very fast. Passthrough GPU has been around since 2009, at least, but really never works in a stable way. Just the other day, a failure on an isolated passthrough GPU with OVMF and vfio had the guest crash the gpu, which crashed the host. Insane things that shouldn't happen with a technology 10 years old.

But now, the gpu "soft-virtualisation" from a software implementation seems to be delivering incredible results so quickly. I really love what is going on.

That said, SSH isn't going anywhere. It's awesome and if you don't like it, your usecase must be non-standard. SSH is secure, requires virtually no resources on the remote or local machine, and everything works all the time. If you're SSHing into a server, or a mainframe, why would you ever want anything except command-line, headache-less interface and secure such as SSH? And bandwith/latency is great regardless of how bad your connection is.