Announcement

Collapse
No announcement yet.

VirtIO-GPU Vulkan Driver Looks To Go Upstream In Mesa

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • darkbasic
    replied
    Originally posted by Quackdoc View Post

    Which is why I said sadly, I know at some point, it was planned, though if you really need to I believe at one point, I had a multi monitor setup working, I cannot remember the details as it was at the level of tinkering, But I believe I had used a Virtio gpu and a qxl GPU. probably wound up using VNC but I can't remember... but what I do remeber is that it was both not elegant, and buggy.
    vnc works, but it's way less convenient than spice. I'll never understand why they undergo such huge achievements like virgl and then nobody cares to do the remaining 0.1% work to make it actually useful

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by darkbasic View Post

    On socket, yes. But you can't use sockets remotely...
    Which is why I said sadly, I know at some point, it was planned, though if you really need to I believe at one point, I had a multi monitor setup working, I cannot remember the details as it was at the level of tinkering, But I believe I had used a Virtio gpu and a qxl GPU. probably wound up using VNC but I can't remember... but what I do remeber is that it was both not elegant, and buggy.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by Quackdoc View Post


    virgl + spice locally works when specifying socket. but thats it I believe sadly​​​​​
    On socket, yes. But you can't use sockets remotely...

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by darkbasic View Post

    Unfortunately virgl is still a no go for windows guests and even when you use it with linux guests you sill won't be able to use it remotely with spice: it won't run over a tcp connection. Because of this I basically have no use for virgl.

    virgl + spice locally works when specifying socket. but thats it I believe sadly​​​​​

    Leave a comment:


  • darkbasic
    replied
    Originally posted by nxij View Post
    Virgl is actually great for driving user interfaces at native feeling speeds. Linux distros and even Android vms with virgl support run their interfaces at 60fps without feeling like VNC.
    For Windows guests one would require a dx11 passthrough or emulation of sorts, vmware actually does this and is able to run the Windows desktop with dwm at a native feeling 60fps framerate and its great for that, it would be great to have some sort of a guest driver that does dx11 on guest side through hosts Vulkan on qemu aswell.

    The performance for heavier tasks though is not up to par or not even close to native sadly, but that is already something else.

    Unfortunately virgl is still a no go for windows guests and even when you use it with linux guests you sill won't be able to use it remotely with spice: it won't run over a tcp connection. Because of this I basically have no use for virgl.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by WorBlux View Post

    Partly that, and partly the fact that the traditional GPU virtualization doesn't fit too well into desktop. Both AMD and Nvidia solutions involve static partition of resources.

    Intel does have a paravirtualization solution GVT-s which seems ideal if not under-developed for destkop virtualization.
    It would still be waaaaaaaay better than the current situation.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by nxij View Post

    Not so sure about it, OpenGL inherently isnt really that limited, virgl in this sense would be slowed down by the overhead in the graphics translation stack, if one could bypass this overhead with Vulkan they should be able to do the same with OpenGL too, I assume.
    Sure they might be able to, but the amount of difficulty would be so pointless. OpenGL IS inherently limited in comparison to vulkan, which is why well optimized vulkan games can achieve 2-4x performance increases over well optimized openGL equivalents. this is why Google is deeming it worthy to port it to vulkan in the first place. as most android apps still support openGL.

    It would be great if dxvk could be loaded so the dwm (the compositing engine of the Windows desktop) was able to be accelerated by it, otherwise i'd imagine diminishing returns having only specific applications accelerated (which would only be smooth in fullscreen due to compositor applying itself over windows applications).

    In that sense the vmware method is ideal as it does exactly what one would expect, I do not know how they do it exactly since its closed source but it works great. Parallels on Mac OS does it well too to the extent where people with M1 macs are able to play newer games and have a smooth UI experience in a Windows vm - thats pretty impressive.
    I would expect that it could, I dont really see why it wouldn't be possible.

    Leave a comment:


  • nxij
    replied
    Originally posted by Quackdoc View Post

    Vulkan on the otherhand can completely change this.
    Not so sure about it, OpenGL inherently isnt really that limited, virgl in this sense would be slowed down by the overhead in the graphics translation stack, if one could bypass this overhead with Vulkan they should be able to do the same with OpenGL too, I assume.

    Originally posted by Quackdoc View Post

    Directx can be done to a... competent degree using DXVK and WineD3D I believe
    It would be great if dxvk could be loaded so the dwm (the compositing engine of the Windows desktop) was able to be accelerated by it, otherwise i'd imagine diminishing returns having only specific applications accelerated (which would only be smooth in fullscreen due to compositor applying itself over windows applications).

    In that sense the vmware method is ideal as it does exactly what one would expect, I do not know how they do it exactly since its closed source but it works great. Parallels on Mac OS does it well too to the extent where people with M1 macs are able to play newer games and have a smooth UI experience in a Windows vm - thats pretty impressive.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by nxij View Post
    Virgl is actually great for driving user interfaces at native feeling speeds. Linux distros and even Android vms with virgl support run their interfaces at 60fps without feeling like VNC.
    For Windows guests one would require a dx11 passthrough or emulation of sorts, vmware actually does this and is able to run the Windows desktop with dwm at a native feeling 60fps framerate and its great for that, it would be great to have some sort of a guest driver that does dx11 on guest side through hosts Vulkan on qemu aswell.

    The performance for heavier tasks though is not up to par or not even close to native sadly, but that is already something else.

    That and really old linux games is about all it is useful for though, of course it is useful to a degree. but to what degree? I can't think of very many use cases that would greatly benefit from flushing it out in its current state. Opengl is just too limited on what you can do with it to get a large ammount of preformance. compare that with the... mostly usable state of it, (from my testing it is great for distro testing). I dont really see that much incentive. making window drivers... kind of, I can see a small degree of benefit. but nothing more than it being worth a side project. Vulkan on the otherhand can completely change this.

    Thankfully it shouldn't be to hard, assuming the vulkan and opengl drivers can be made for windows, Directx can be done to a... competent degree using DXVK and WineD3D I believe. but I haven't tested it yet, though do plan to do so, Running everything under DXVK and WineD3D

    Leave a comment:


  • zexelon
    replied
    leipero I agree not compiling with SDL is a very odd choice, but I found quite a bit of chatter with the Ubuntu managers and they chose to drop support for SDL in qemu in their main repos after I think it was 18.04.

    Thanks for the pointer I will look at that PPA, yes Pop_OS is Ubuntu based so if it works for Ubuntu typically it will work just fine for Pop_OS.

    Leave a comment:

Working...
X