However the only effect in the Windows 7 guest was that the screen resolution of the guest no longer adapts to the window size and hence the spice desktop is not as seamless as with QXL. There is no 3d acceleration in the guest.
It is a thread by someone who already has gpu acceleration and complains about poor performance. My problem is that I don’t have gpu acceleration in guest at all. My card is GTX680, I have 32GB ram and i7 3770.
IMO there should be enough in that thread to either figure out for yourself or Google using keywords,
First, in that OP’s original post, he described how the GPU was configured, and then he described what was implemented in the Guest.
Then, in a later post in that thread, I referenced an IBM laboratory project which provided more detail how their HostOS and Guests were set up.
Left unsaid at the end of that thread is that the specific command option /node required a Win7 hostfix.
If you’re running a different Windows in a Guest(eg Win8, Win8.1 or Win10), although there doesn’t seem to be anything I found on the Internet, a hotfix may be required for those OS as well.
If you’re not familiar with Microsoft policy about, and what is a “hotfix,” it’s a patch available only on request and a link to the patch is often not public. You have to request a hotfix from MS Support.
Also,
Keep in mind that any kind of GPU pass-through and/or acceleration is very much on the bleeding edge, so always search for, and prioritize articles as recent as possible, ie. within the past 6 months, then the last year, then anything older than that.
So,
For any threads on this topic in these Forums,
Don’t necessarily rely on the information provided… Do your own search, and utilize info in these Forums for only however you value it as info that might help fill out whatever you find…
Sorry but I don’t find that other helpful at all. Also the word driver is not even mentioned there. My CPU is not Opteron like and my guest is not Win 10. Also I have no idea what frequency scaling is and all the rest of the talk discusses things which I am not really asking for. To put it differently - it has a lot of extra info which only blurs my mind
All I need to know is very simple:
How to enable gpu acceleration inside Win7 guest. Not pass-trough. As far as I understand from the link I posted in the OP it should work exactly like that - using the GPU of the host for acceleration in the guest. I read that virgil3d doesn’t support Windows guests and I wonder if KVM itself supports it, considering the info on the kernel page. Please note that I am not familiar with the intricacies of all the underlying technology, so I am asking purely from the viewpoint of a user who wants to run CG apps inside a Windows 7 guest. That’s all.
A long time ago when I used VMWare workstation it didn’t need anything special for that. I just had to install the guest and guest 3d acceleration was available out of the box. So I just need to have the same but in KVM.
The top Google result is the following. Although it’s based on Fedora, it has enough info that other distros can try the configurations. The only unknown is whether the distro kernel maintainers removed any of the required kernel modules, so success isn’t guaranteed but there is a high probability.
Recommend you study those topics you say you don’t understand, when you’re on the bleeding edge you won’t find easy to use tools and things won’t always work as expected so you’re on your own (or you can post questions about specific topics in these Forums).
In that other post, the Opteron CPU isn’t central to his configuration but useful. It only means that there are two CPUs already in his system without installing an add-on graphic card which you’d likely have to do.
Practically a CPUs nowadays can operate at different speeds to save energy or provide maximum capability. On bare metal, this is not an issue but the OP in that thread wanted to make sure that the Guest would be able to fully capable of using the HostOS capability. My response was that if the HostOS is set at max capability and never throttles down, then the Guest can do whatever it wants and be fully capabile. So, you need to configure that in the HostOS, even perhaps overclocking.
The main takeways from that post…
You have to configure your HostOS as described in the thread (and elsewhere). Or, better yet follow the highlights in the kraken post.
For your Win7 Guest, you have to install Windows Enlightenments and possibly install the required hotfix.
I’d also recommend you take a look at the virgil3d home page itself. The author is fairly up front on what he believes works or not, and the architecture. As he describes, when implemented it doesn’t require hardware pass-through, but on the other hand I highly doubt that it’s possible to have virtualized 3D graphics without HostOS hardware capability. He also doesn’t fully describe any hardware GPU or CPU requirements and doesn’t really describe what his own machine has… So, there really is very little there for anyone else to reliably replicate his project. It’s worthwhile, it’s interesting, but anyone trying to replicate should understand it’s problematic given insufficient information.
That’s funny. When I asked about pass-through almost 2 years ago you also said that I have to wait longer as it was still new, now this question is bleeding edge again
I will check the links, thanks. But I wonder why this matter is so apocryphal as you explain. If the technology has been available in VMWare for years, why is it not available in KVM… Also if it is actually there it makes sense to be documented, so people can use it. Or are we supposed to find all the info through the personal blogs of X, Y or Z? Where do X, Y and Z learn from if that is not documented?
Speaking of pass-through, a little bit of history of what I tried:
When I was fighting with it before, I found that when I set UEFI boot for my videocard in BIOS setup the machine doesn’t boot (blank screen). I don’t know why but it is the only device for which UEFI boot doesn’t work - no idea if the reason is the MB (P8Z77-V /Z77) or the videocard itself. Additoinally someone explained that it may not be possible to assign the external GPU of the GTX680 to the guest and at the same time run the host on the Intel HD 4000 of the CPU. Or even if it was possible - I wouldn’t be able to un-assign it without reboot. So I gave up on the whole thing. When I found the info about kernel 4.4 that gave me new hope though, for a non-pass-through method.
Also I just saw this video which does exactly what I was hoping for before. Considering that I have 2 monitors - it would be ideal if I can do the same. However is it possible without UEFI boot for the GTX680? Or is the pass-through still bleeding edge? Any docs/guides?
I am really trying to get rid of the dual boot, so I wonder what would be the right approach.
Development along different tracks will generally proceed at different rates.
And, although there are many benefits to open source, often times resources aren’t focused in one area the way a private company can by edict.
Also, implementation can be different… The VMware virtualized display driver likely has its own architecture which may have advantages (and disadvantages) the common User won’t see.
It’s possible to speculate forever on why one thing isn’t developed in lockstep with something else, and in general across all technologies competitors usually don’t advance in concert but in a leap-frogging fashion.
In general,
You have to set the method of boot (MBR vs UEFI) when an OS is first installed. Once configured, I don’t know that there is any practical way to switch short of a complete re-install because it’s fundamental to how the disk is read.
I think you are discussing something different from what I talk about. Please let me show you what I mean about UEFI:
Considering that “UEFI only” results in non-bootable PC and any of the other 2 options actually use Legacy OpROM - could you please explain if it is possible to achieve what is shown in the youtube video I shared and if yes - how do I configure it?
As I described, UEFI for the most part is only relevant to how the physical disk can be read, it shouldn’t have anything to do with the GPU.
The “OpROM” probably is what is more commonly referred to as the MBR.
Your referenced YouTube video only displays what might be possible if you are successful configuring virt-io GPU.
I don’t know if you can configure that on your hardware, it’s a possibility… But as I’ve said in my previous posts there isn’t enough documentation for the various technologies to know for sure that it will work for you, and that’s possibly because it’s so much on the bleeding edge documentation is a second thought to just getting something to work, and what they got to work hasn’t been tested on enough hardware to know where it works or doesn’t.
So, sorry there isn’t a better answer available but no one can promise something that can’t be promised (well, an erstwhile President thinks nothing of that). You can go on the mailing lists or IRC for those technologies for help and opinion, but there will probably still be no guarantee of success.
It seems to me you are confusing UEFI with GPT as you talk about UEFI as of some opposite of MBR. However UEFI is not a replacement of MBR but of BIOS. So it is not UEFI<->MBR but rather UEFI<->BIOS and just one of UEFI’s features is GPT(<->MBR). Also option ROM (OpROM) is not master boot record (MBR). These are different terms serving different purpose.
Well, yes…
The UEFI describes how the disk is accessed (ie not directly on boot, requires a reboot) securely.
And yes, MBR is probably more relative to GPT but only for the part that holds the sector addresses.
I guess the OpROM is something, I’ve always observed ROMs have multiple boot options and never thought that the word “option” was necessary since it denotes nothing unusual.
And, I did mis-speak about the OpROM and MBR.
