When will the 'egl-headless' display merged to the kvm-qemu branch

[lincchenl]

I was testing proxmox VE on a xps13 9350 host with a 6th gen i7 cpu and a iris540 gpu onchip.
The trial of passing through or using intel gvt-g works fine for me and I can see the intel graphic driver is successfully installed. My need is to use spice protocol while using gpu-acceleration at the same time.The official wiki of proxmox suggest did not help, so I looked up for other solutions. And I found Intel's guide: github.com/intel/gvt-linux/wiki/Dma_Buf_User_Guide ,which seems perfectly meet my demands.
The only diffrence is to modify the config file with: 1. "vga:none" ; 2."args:-display egl-headless -spice......." .
I tried it out on proxmox and just find out the error output:"kvm: Display 'egl-headless' is not available" . So I want to ask when will the feature merged into proxmox release?

Many many thanks!

 

[lincchenl]

seems that only need to add the "opengl_dmabuf" switch in qemu compiling.

 

[EuroDomenii]

The feature "and also enables the use of vGPUs (aka mediated devices) like Intel KVMGT (aka GVT-g) or Nvidias vGPUS." has landed since https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_5.3. Shouldn't opengl_dmabuf be enabled by default?

 

[dcsapak]

no, qemu is not compiled with opengl by default, and the use case is very narrow, this only works with with mediated devices and even then a user can select a vga type in our gui and still get
vnc capabilities, or use a remote desktop in the guest to utilize 3d rendering

 

[lincchenl]

no, qemu is not compiled with opengl by default, and the use case is very narrow, this only works with with mediated devices and even then a user can select a vga type in our gui and still get
vnc capabilities, or use a remote desktop in the guest to utilize 3d rendering

Thanks for ur reply.

yep I know an extra vga will provide the vnc capability.
The problem is an extra vga card introduces many problems among which the most severe one is that 3D accerleration fails because the default video card is not the one passthroughed.

As to Using the RDP client, which is now my solution,still have something uncomfortable.
1.If system fails to boot into the desktop,I had to add the vga provided by kvm(not used by default because the reason before). not very friendly for guys like me who likes to try dangerous operations on system, or even more I just wanna to use passthrough while access the bios or pre-boot framebuffers at the same time.
2.The rdp is nearly perfect while it still has some limit even after we boot into desktop. For example 3Dmark failed to create windows during RDP session.

What's more, I installed macos on pve, and I just wanna to passthrough my intel graph card to it, but mac refused to load intel kexts when an extra vga card is attatched.

So as the reson above, just introducing the function will bring us a staight and simple solution for intel graph cards or even further amd sr-iov cards. I will be very happy to hear good news from it(or the feature will never be considered?)

 

[dcsapak]

can you open an enhancment request here: https://bugzilla.proxmox.com/
we can discuss it there (and maybe get some opinions about it from my colleagues)

 

[dcsapak]

or even further amd sr-iov cards

this will not work, since it only works when the host has control over the card, which is not the case with classic sr-iov (at least at the moment, i saw some patches flying around the qemu list which may get
a solution, but i do not know if the hardware vendors have to implement special drivers for this)

 

[rkk2025]

Has a enhancement request been filed? I cannot find anything on the bugzilla.proxmox.com related to this.
@dcsapac is there any downsides of having QEMU compiled with OpenGL support?

EDIT: Opened one myself: https://bugzilla.proxmox.com/show_bug.cgi?id=2603

 

[dcsapak]

Has a enhancement request been filed?

afaics no

is there any downsides of having QEMU compiled with OpenGL support?

mhmm.. not sure, my tests of egl-headless feature was very unstable, but if we do not use it by default, maybe ok (a few libraries more dependencies would be added, but i guess this can be ok)

 

[jic5760]

Are there any updates to this?

 

[dcsapak]

sorry, not yet, i'll try to look at this again in the future (or maybe i can get a colleague to do it)