So basically Looking Glass will have all the features you would want from Nvidia Pascal and makes them available for any GPU.
Vega and its mainlined driver look so sexy right now… 
Hey Guys,
How would I request to test Looking Glass? I tried private messaging @gnif however it says I cannot message that user.
Current have a Dell Precision M4800 that I use everyday (i7-4800MQ, 16 GB of RAM, Quadro K1100M). Am looking for a way to solve my portability issues (having to require a TV/Monitor to plug in to) so I can continue using it at University when I start Computer Science.
Sorry but you don’t, you will need to wait for the release like everyone else 
Ah oh well, at least I tried
What time frame are we looking at for the public release?
TBD at this point, watch my latest video, it explains what needs to happen first. We would also like to have good documentation at launch, @SgtAwesomesauce is working on that too.
I see, still some work to do with AMD cards, some sync issues, driver signing etc. Well if there is anything I can do to help I wouldn’t mind pitching in, have plenty of time at the moment :).
Well we gave him like 4 grand so I’m pretty sure OP will deliver. xD
I wasn’t happy with those 4k scaling tests earlier, I felt there was something off, and I was right, the NVidia drivers were not really switching down from 4K, for the other screenshots. Here is a true comparison between 1200p and 4K scaled to 1200p in realtime.
Native 1200p
4K Scaled to 1200p
Linked so you can view them full size for comparison.
Sorry about the lighting change, ARK seems to skip time when you restart the game…
There is a difference in the smoothness but I am not sure if it is worth it at the moment to work on that.
It was just out of interest, but there was a reason to do it… pushing up to high resolutions made windows switch to high DPI mode, which I had not countered for, it exposed some bugs that I had not yet figured out that @celmor had reported.
Don’t get me wrong I do realize that this is important especially for ui scaling however what I meant is shouldn’t you try to replace the nvidia code first and make it opensource so more people can help? Because right now it looks like you want to finish it and make a documentation for it before going open source.
Again I have no problem with that after all it’s all up to you but it looks like you like the hard way.
There is nothing there to replace… I could push the code out today but I don’t want to until the AMD issue is resolved (which we think might be, just waiting for @wendell to do some testing to confirm). And the entire project is useless without the ivshmem driver from redhat.
Outside of that I want to give @SgtAwesomesauce enough time to write some good documentation on how to get it setup.
After all that, it’ll go out.
After a quick google search I could only find that redhat dropped support for Ivshmem and only support something that works like ivshmem-plain.
I am definitely out of my league. I just think that there must be some more transparency in what are we waiting for and what can we do to push the tech forward.
Correct, it’s the same thing just implemented a little differently to plain ivshmem, we are using ivshmem-doorbell for interrupt notifications, which is current.
I thought we had been pretty clear… ivshmem was written with only linux in mind, a windows driver was never written for it because there was no use case. I wrote one two months ago which was upstreamed into the official VirtIO git repository shortly after. There is a video of the initial release which will shed light on why a windows driver was never written… they were thinking cloud, massive data, network latency, etc.
In order to continue this work (note, this was all proof of concept at this point and I had not even discovered the NPT problem, let alone the fix) I worked with windows in test signing mode as windows vista 64bit and later will not load a self signed driver unless you’re in test signing mode.
This was fine during the development of the driver, but since Looking Glass needs to run along side applications that contain anti-piracy, anti-cheat, etc… it can’t be run in test signing mode or these applications will refuse to run.
In order to proceed I personally purchased out of my own pocket a driver signing certificate and spent a few weeks jumping through verification hoops to prove my identity. This certificate contains my full name, address and various other chunks of information I would rather remain private which is why I will not release a build that I have signed.
Red Hat has confirmed they will sign a driver and knowing this I dismissed the issue figuring a build would be released in the near future when they are ready… besides still at this point it was a proof of concept, I was literally drawing the frame buffer into a ncurses text console from the guest.
From my point of view at this point, the concept was still to be verified as feasible, as such most things that I wrote were hacked together, no error checking, fixed resolutions, hard coded values, etc…
This is when I discovered the NPT performance issue, I was unaware of this problem up till this point. I had a performance issue I couldn’t nail down and had to spend further time into learning how KVM works, then how AMD SVM works, and then how Qemu works… etc. A huge undertaking in itself.
After fixing it I had no idea the publicity it would receive, and then @wendell mentions to the world that the next step is to “copy the framebuffer to the host”, and here I am sitting on a prototype that did exactly that! So I got in touch with @wendell, shared with him my build at that time which contained all the aforementioned hacky code. This is why that he stated it was rough around the edges… that was an understatement.
The project was too rough to open up to a group of open source developers, it had no clear direction in it’s internal design, too much was hacked together junk just to verify the idea. But the cat was out of the bag… so the last few weeks now I have been working daily, 5-6 hours a day on this project, if I was to guess I would say I have spent over 200 hours on this entire project so far from initial conception.
A few days ago I decided it was time to poke Red Hat again and ask to have a build of the driver released:
From a code perspective, Looking Glass IMO is very stable now, the code has a few things I would like to clean up in it still, but nothing preventing a release anymore. It is lacking some features still, but nothing that will prevent it’s successful usage.
Getting it setup is a little tricky, a few things in windows that needs to be configured first, customization to the VM’s command line, as well as getting permissions correct for starting the ivshmem-server which is used as the shared memory mediator. Documentation on these details needs to be clear and concise before it’s released, not after.
@SgtAwesomesauce is going to document everything he can, but the initial focus will be on a guide to get it up and running as easily as possible. Once this guide is ready, verified to be accurate by @wendell, @celmor and myself we will be in a good position to release. Any additional documentation outside of this initial guide will not hold up the release.
One thing that @wendell is going to try to pursue is obtaining permission from NVidia to enable support for NvFBC on consumer cards. Unless you are “ShadowPlay” or “Steam” the NVidia Capture API refuses to run on consumer cards (even though it can), it will only run on professional cards like Quadros. I have been able to write the code anyway and test since I have a GTX690 I hacked into a Tesla K5000 quite some time ago now. This though will not affect the release of the project, as we have DXGI Desktop Duplication to fall back on if NvFBC can’t be used.
Edit: I forgot to mention a ton of time still needs to go into Qemu, it’s virtual i8042 PS/2 controller has a problem that the mouse stream to de-sync at random, and windows then assumes the mouse is faulty and stops using it (in short, you lose mouse input). This though I have deemed outside of the scope of Looking Glass as I have already proved I can cause this fault with the libvirt Spice viewer also, and as such Looking Glass is not the cause.
If someone want’s to help this project now… go fix that bug! It’s VERY annoying. Likely a race condition with interrupts.
I expect that if that bug is not fixed before Looking Glass is released, the bug is about to get a ton of attention by everyone, since Looking Glass allows you to play games where you move the mouse a ton, you’re quite likely to trigger the fault. This also needs to be in the guide by @SgtAwesomesauce so I don’t get a ton of spurious bug reports.
… Qemu, it’s virtual i8042 PS/2 controller has a problem that the mouse stream to de-sync at random, and windows then assumes the mouse is faulty and stops using it (in short, you lose mouse input).
Has this bug been reported on QEMU’s launchpad? If so, can someone give me a link?
I only found some very old references to it, I did mail the qemu mailing list a few weeks back when I started to dig into this, but decided to put it aside until I get Looking Glass out.
The reason it hasn’t been noticed by many yet is because libvirt will create a vm with a tablet device which it uses for absolute positioning. For games though, we need relative positioning, and as such Looking Glass never uses absolute.
You can trigger this fault by removing all tablet devices from the guest VM which will force Qemu to use relative mode… then once windows is running, throw your mouse around like crazy for a 10 seconds or so.
You can also trigger it if you only have a virtual PS2 KB & Mouse attached (not USB). Go into notepad and hold a key down, then move the mouse around, you will see the mouse lockup, and sometimes the key you held will change as the mouse stream data is getting interpreted as keyboard data.
This is because the PS2 keboard and mouse both run through the i8042 controller, just like IRL.
Edit: The windows event log also logs a fault with the i8042 controller driver.
Edit2: Virtual USB KB & Mouse has it’s own problems too… IMO it would be best though to fix the i8042 controller as it’s much simpler then trying to figure out why the USB stack will stall from time to time.
Thanks for the info this is the kind of info i was expecting and actually I am sorry if you mentioned it before in this thread.
That is the main reason why I asked you to make a new thread so we can now distinguish the project from the bloat about the fund me campaign. You said something about a blog so I will ask you in your free time to make one and if you are able to include this post in it. I think it sums up everything nicely.
As someone who has to work with some shit documentation at work: Thank you so very much.
