| View previous topic :: View next topic |
| Author |
Message |
_______0
Guru
Joined: 15 Oct 2012
Posts: 521
|
 Posted: Fri Jun 21, 2013 9:06 pm Post subject: wine vga passthrough? |
 |
|
hi,
Upon reading latest crazy VM passthrough solution I came up with this idea.
Why not use xen/kvm/whatever GPU passthrough code (obviously with necessary modifications) to lift wine's GPU emulation overhead and allow to tap directly into hardware?
I think this is the cleanest, simplest, fastest solution for linux full gaming experience.
thanks |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Fri Jun 21, 2013 10:50 pm Post subject: |
|
|
| WINE does not emulate a GPU. It provides graphics library calls that allow programs written for the Windows graphics model to communicate their graphics requests to a Linux graphics driver. |
|
| Back to top |
|
|
_______0
Guru
Joined: 15 Oct 2012
Posts: 521
|
| Posted: Sat Jun 22, 2013 11:25 am Post subject: |
|
|
| Hu wrote: | | WINE does not emulate a GPU. It provides graphics library calls that allow programs written for the Windows graphics model to communicate their graphics requests to a Linux graphics driver. |
Mmm... what about my idea?? I think it's awsome!!A stand alone GPU passthrough code for wine.
Whatever WINE does is still stuck in dx9, my solution bypasses the complicated part of having to port GPU code to linux and use m$$$$ graphics natively. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Sat Jun 22, 2013 11:52 am Post subject: |
|
|
Err, Hu's reply says your idea can't work. Because it really can't. VMs emulate a GPU. And you can replace that with passthrough. It then works by installing the native driver for the graphic card inside the VM. But wine only implements userspace, there's no GPU emulation or emulation of any other kind of hardware, you can't install hardware drivers on wine.
The only way you could run the Windows driver on Linux would be to implement something like ndiswrapper. But the wrapper for the GPU driver would be much, much more complex, and even ndiswrapper is a nightmare, so no way you could get the GPU wrapper to work reliably. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Sat Jun 22, 2013 4:26 pm Post subject: |
|
|
Many people believe their own ideas to be awesome, especially if they ignore technical complications. I think it would be awesome if I had a wormhole that would let me get from home to work in zero time, but physicists much smarter than me have yet to find a way to make it work the way I want.
As Gusar stated, there are massive technical hurdles to making this work. Interoperating with wrapped Windows drivers is difficult enough when the hardware is resilient in the face of problems. GPUs have such extensive processing and DMA access that there is a good chance you will crash the whole machine if the wrapper is not perfect. It is probably more practical to improve the existing open Linux graphics drivers to a level that no passthrough is necessary than it is to provide the infrastructure to support a passthrough, even taking into account how difficult it is get certain companies to cooperate in improving the open Linux drivers for their hardware. |
|
| Back to top |
|
|
BradN
Advocate
Joined: 19 Apr 2002
Posts: 2391
Location: Wisconsin (USA)
|
| Posted: Sat Jun 22, 2013 10:45 pm Post subject: |
|
|
| It sounds like ReactOS might be able to load graphics drivers in a VM context. A lot of the code is the same as WINE anyway, so it's going to be a pretty similar thing to what you're trying to accomplish, only here there is a windows-like kernel that can actually operate some drivers. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Sun Jun 23, 2013 9:30 am Post subject: |
|
|
| BradN wrote: | | It sounds like ReactOS might be able to load graphics drivers in a VM context. A lot of the code is the same as WINE anyway, so it's going to be a pretty similar thing to what you're trying to accomplish, only here there is a windows-like kernel that can actually operate some drivers. |
ReactOS is a full standalone operating system, no VM stuff about it. Also, it isn't actually using much wine code from what I know. But its biggest problem is that it isn't anywhere near complete, I very much doubt it's capable of loading a GPU driver for modern GPUs. |
|
| Back to top |
|
|
BradN
Advocate
Joined: 19 Apr 2002
Posts: 2391
Location: Wisconsin (USA)
|
| Posted: Sun Jun 23, 2013 10:08 pm Post subject: |
|
|
| Gusar wrote: | | ReactOS is a full standalone operating system, no VM stuff about it. Also, it isn't actually using much wine code from what I know. But its biggest problem is that it isn't anywhere near complete, I very much doubt it's capable of loading a GPU driver for modern GPUs. |
Right, but nobody's going to run reactos standalone, maybe unless they're masochistic. It could make sense running it in a VM if you can get some modern games to work with full accelerated drivers.
I know it can load some real video drivers, but I don't know if it can run the particular drivers _______0 is interested in, and beyond that, if they would work in a pci pass-through environment. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Sun Jun 23, 2013 11:13 pm Post subject: |
|
|
| BradN wrote: | | It could make sense running it in a VM if you can get some modern games to work with full accelerated drivers. |
That's a really huge "if".
Then there's the thing where if you're going to run a VM, why not simply use Windows? That way you get the highest possible compatibility. Yeah ok, you need to buy a license *cough*, while ReactOS is free, but if Windows games are what you're interested in, that's not a big deal. A lot of people get Windows with their machine purchase anyway. |
|
| Back to top |
|
|
fpemud
Guru
Joined: 15 Feb 2012
Posts: 349
|
| Posted: Fri Jun 28, 2013 2:30 am Post subject: |
|
|
Is qemu able to passthrough the primary graphics adapter?
If the answer is yes, I think we can play windows game in virtual machine in full speed.
The other part of the system won't need the graphics adapter when there's a fullscreen game running, I suppose.
It's easy to archive a wonderful user experience except a long loading time by automating the whole process of start-vm/start-game/exit-vm. |
|
| Back to top |
|
|
BradN
Advocate
Joined: 19 Apr 2002
Posts: 2391
Location: Wisconsin (USA)
|
| Posted: Fri Jun 28, 2013 7:39 pm Post subject: |
|
|
| I think you would need a 2nd graphics adapter - a builtin + a good add-in card could work that way. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Fri Jun 28, 2013 8:20 pm Post subject: |
|
|
| BradN wrote: | | I think you would need a 2nd graphics adapter - a builtin + a good add-in card could work that way. |
Yep. The GPU you pass through to the guest is not available to the host system. So you need two GPUs - one for the host, one for the guest. That's true for all hardware BTW, not just GPUs.
Beyond that, you need kernel 3.9 and its vfio-vga driver. And of course, you need a motherboard with a proper AMD-VI or Intel VT-D implementation. A lot of motherboards do not have that, despite claiming support. |
|
| Back to top |
|
|
fpemud
Guru
Joined: 15 Feb 2012
Posts: 349
|
| Posted: Fri Jun 28, 2013 11:52 pm Post subject: |
|
|
A 2nd graphics adapter is ok for me since it hides in the computer chassis.
Kernel 3.9 and vfio-driver is simple.
I can also give my board a double-check for VT-d support.
But do I need a 2nd monitor? I have an excellent monitor, I don't want to put another one on my desk.
BTW, is there any doc describe what is hindering us from passing through the primary device?
The host system don't need the graphics adapter when there's a fullscreen guest running. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sat Jun 29, 2013 3:08 am Post subject: |
|
|
| fpemud wrote: | | BTW, is there any doc describe what is hindering us from passing through the primary device? |
There are a lot of docs describing how things fit together, but I don't think one explains why it is impossible; that is likely because it is not necessarily impossible, it rather needs to be implemented. Xen can do such thing, as you can see at http://wiki.xen.org/wiki/Xen_PCI_Passthrough; the "Overview of passthrough" gives some short details on how Xen does this. Now, Xen is written to have the kernel do this for actual virtual guests; adapting this to work with Wine instead (and adapting Wine to work with this), is a whole new implementation. It is possible, but who's going to write the complicated part to make it work natively? |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Sat Jun 29, 2013 7:33 am Post subject: |
|
|
| fpemud wrote: | BTW, is there any doc describe what is hindering us from passing through the primary device?
The host system don't need the graphics adapter when there's a fullscreen guest running. |
Passing the GPU through requires unbinding it from the host. You can't do that if the GPU is in use (by the host's X for example, or even by a KMS framebuffer console).
Xen does support passing the primary GPU, but the only way I can see this working is that the GPU is simply never used on the host - from boot on, all you get is the guest display, and the only way to access the host is by remote (ssh, web interfaces, Xvnc or something similar). |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Jun 29, 2013 9:38 am Post subject: |
|
|
| fpemud wrote: | A 2nd graphics adapter is ok for me since it hides in the computer chassis.
Kernel 3.9 and vfio-driver is simple.
I can also give my board a double-check for VT-d support.
But do I need a 2nd monitor? I have an excellent monitor, I don't want to put another one on my desk.
BTW, is there any doc describe what is hindering us from passing through the primary device?
The host system don't need the graphics adapter when there's a fullscreen guest running. |
To clarify, even 3.8 worked for passthrough, as I used it for qemu. But you do need mb support and the vfio drivers
I have an nvidia 210 as my "system" gpu and a radeon that I use as passthrough.
Both cards go to my single monitor (2 hdmi, selectable from monitor) and just swap back and forth as needed.
Edit to add: Radeon cards seem to be better at being passed through,
I've had problems trying to passthrough nvidia cards and I've read of others having problems.
I also passthrough some of the usb ports and an extra network card I had added when I built the sytem.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
i92guboj
Bodhisattva
Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)
|
| Posted: Sat Jun 29, 2013 12:40 pm Post subject: |
|
|
This whole thing is nonsensical.
WINE already does that, since it's just an API layer that runs windows object code on top of a linux kernel, x11, libsdl, mesa and a few other libs. I can't image how anything could be any more "direct" than that, unless you mean to re-implement wine in assembler and link it to a wine.ko kernel module. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Jun 29, 2013 1:02 pm Post subject: |
|
|
There are some things that wine doesn't do well, some games, etc.
That's where xen or qemu have an advantage, as they can run windows directly not emulate.
The downside, is one needs to have windows on hand with a license.
I do agree that it's silly to think that wine will ever have vga style passthrough as that's not it's goal.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
i92guboj
Bodhisattva
Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)
|
| Posted: Sat Jun 29, 2013 1:11 pm Post subject: |
|
|
| Anon-E-moose wrote: | There are some things that wine doesn't do well, some games, etc.
That's where xen or qemu have an advantage, as they can run windows directly not emulate.
The downside, is one needs to have windows on hand with a license. |
Wine is sub-optimal in many ways. I won't argue that. I am just saying that it can't really be any more straight than it ALREADY IS.
That some parts of it needs some love is a fact, and that will be fixed the day that someone decides to fix it, I guess. But it reallly doesn't need something like the thing in this thread is discussing. As I said, the only way to bring it closer to the machine would be to convert it in a kernel module, and that's xen, isn't it?
| Quote: | | I do agree that it's silly to think that wine will ever have vga style passthrough as that's not it's goal. |
It already access the vga card as straight as any other linux program. Wine, and anything running on top of wine, is just as close to the vga card as kwin, neverwinter nights, glxgears or libsdl. If wine is not alright, then no linux program is alright in that respect. 
I still don't get what you people are trying to fix. If you want to improve the wine performance, I'd start by fixing the linux graphics stack as a whole. Otherwise you are shooting at the wrong place. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Sat Jun 29, 2013 2:38 pm Post subject: |
|
|
| i92guboj wrote: | | I still don't get what you people are trying to fix. If you want to improve the wine performance, I'd start by fixing the linux graphics stack as a whole. Otherwise you are shooting at the wrong place. |
I agree with you, improving the Linux graphics stack is both more useful and probably easier than doing as the OP described. As I understood it, OP was under the mistaken belief that individual Windows programs had enough GPU-related knowledge that they could somehow run better if given direct hardware access than if given mediated access by way of telling Wine to tell the X server to tell the kernel to render something. However, Windows games do not have that knowledge, and would need a full Windows graphics driver available to receive their commands. That driver in turn would require substantial infrastructure to get it to work within a non-Windows kernel. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Sat Jun 29, 2013 11:59 pm Post subject: |
|
|
| i92guboj wrote: | | Wine is sub-optimal in many ways. I won't argue that. I am just saying that it can't really be any more straight than it ALREADY IS. |
Of course it can. Wine relies on a Direct3D -> OpenGL translation layer. Or the be exact, on a HLSL -> GLSL translation layer. Since the two shading languages don't have a 1:1 mapping, there's inefficiencies.
A different, more direct approach would be to use a D3D Gallium state tracker, which would translate HLSL to the Gallium IR (intermediate representation). But such an approach would limit wine to Gallium drivers (basically radeon and nouveau), which would leave out Intel, the Nvidia blob and the AMD blob.
| i92guboj wrote: | | It already access the vga card as straight as any other linux program. |
No it doesn't, see above. Windows apps talk D3D, Linux drivers talk OpenGL. |
|
| Back to top |
|
|
|
Kernel & Hardware
