Return to

A little teaser of what is to come :)



Hopefully this is not too bloaty but what if we could start as RDP and then somehow seamlessly drop to LookingGlass?


It’ll be open source, so someone else can tackle this problem if they want. Just making this thing work well in the first place is a huge task itself for a single person.


Right, I’m sure after release that can be worked on by those interested.


So automatic login or direct connection from GPU to monitor is still required for that. I assume direct connection will still have less latency than FrameRelay, and will be preferable for gaming if you have a second monitor and cables. Still super useful for cross-platform productivity of course!


Go back up a little and read what I posted, with vsync disabled you get latency so low I can’t measure it.


Aye, I read that, how bad is tearing though? (I never run vsync in native Windows and never had issues).

So overall what I gathered from this thread, FrameRelay is so fast and no latency you basically see no difference compared to separate connection to monitor, so you can freely move ot around and swap around as you like/need without switching the monitor input.

Great work overall, am eagerly awaiting release since I want to finally setup my system using VM Windows and Linux host!


It depends, because my two monitors are so close to sync already it looks pretty nasty as the tear is in a pretty constant spot ± some jitter, but if I create a custom resolution on the guest and bump it’s refresh a bit so it’s out of sync (59Hz or 61Hz) it’s just like running with vsync disabled like you have now.



Valve is smart enough not to do this, but Ubisoft and EA with Uplay and Origin? I wouldn’t doubt they’d do that.


Hey @gnif do you want to make a new thread on the forum more specific to the topic because this one includes 300 posts about the fundraiser.

I can only suggest that is named project looking glass (framerelay) and also if you think you will be including a lot of updates make 1 or 2 more posts that you can later edit to include info. So when someone new comes the info will be at the top.


@gnif Where is Vsync enabled in Looking Glass? The host, the guest or both? Since you are testing with a Pascal GPU, could you test how it behaves when turning on “Fast Vsync” in driver settings?


This project looks amazing. It’s exactly what I wanted!

One question though. You say it won’t work before the user logs in on Windows due to their security model. But I currently use Synergy with a Windows 10 tablet, and I am able to control the keyboard and mouse before logging in. I can therefore log in through Synergy. How do they manage to do that then?


Controlling the keyboard and mouse is easy, capturing the frame buffer is not.

@karmek The guest only sends changes as fast as the host asks for them. If the host has vsync turned on it will be @ whatever your refresh rate is. If vsync is off it will be at whatever the guests refresh rate is, which exceeds vsync if there is hardware cursor movement regardless of the guest side configuration.

@anon5644329 I am thinking about staring a blog rather then posting to a thread.


… or sharing some documentation ahead of time while you wait for various things to land upstream, even if there’s no code you can publish yet …

I’ve been wondering, are there any implications or complications of using NvFBC wrt DRM ? Reason I’m asking is that I’ve recently learned there’s a WHQL requirement for audio drivers to disallow software loopback recording of drm protected streams, and I’m wondering if such a thing could cause complications. I’m not sure how DRM testing/development works for audio/video (are there drm test streams or some such weird stuff?)

With NvFBC / Capture SDK (if that’s what you’re using), does the frame live in GPU ram or system ram ?

Is NvFBC a constant source of frames, or does it give you a frame only when something renders, or when something changes, or any time the host asks? if the screen contents is not changing, is anything happening?

Re x399 and pcie, I’ve learned today that pcie supports hotplugging - I wonder if it’s possible to reset / reinit a vega card somehow like that (pcie extension cable modded with a momentary power switch that breaks the circuit between relevant pins)? I realize this is not practical as a solution for end users, but might be fun to try regardless. This should be testable on intel too since pcie is pcie.


Hot plugging PCIE is always a huge risk. It depends on the device. If it’s a Blackmagic card in use… Instant BSOD or Kernel Panic.


I don’t like the idea of PCIE hotplug. Especially considering the motherboard will supply up to 75w to a device, you’ve got theoretical potential for burning out pins.


@gnif I’d be extremely interested in how the latency and frame timing behaves on a variable refresh rate monitor, I look forward to doing some testing (just picked up a freesync monitor).

As for PCIE hotplug…its a mess right now, I’ve had to deal with some boards, and its up to how both the card and the motherboard are implemented. Biggest issue is what @FurryJackman mentioned, so many cards don’t handle ejection properly and kill your OS. As for pin burnout I’ve only had one system do that. Most server boards now properly support low power handshake before cranking up…consumer boards still got some catching up, in many cases it can be fixed in a bios update (if the manufacturer feels like it :unamused:).


If the motherboard is desingned properly (most aren’t outside of the server industry) they will have a Hot Swap Controller which current limits the device while it charges it’s caps. This is not only to prevent damage from adding a sudden load, but also to prevent the inrush from pulling down the power supply for a split second locking up the host system.

NvFBC will not capture a DRM protected stream, nor will DXGI FrameBuffer, there is nothing we can do about this. However most people using this will be playing games or doing CAD work which do not enable DRM. If you wan’t to watch DRM videos, just use the host.

NvFBC isn’t very clear about this, from what I can tell copies it to system ram, unfortunately it allocates this buffer and provides it, there is no way to give it the address to the shared memory and have it copy directly into it.

It can be either, only on changes, constant or a mix of both. We are using a mix of both simply to prevent stalling out the pipeline, so changes are sent instantly, but if nothing has changed for more then ~30ms we trigger a capture event anyway.


I would too :), alas I don’t have one. In theory we would never have tearing, and thus vsync would not be needed, giving us <1ms latency.


Pitty mirror driver miniports got removed.


However, a special GDI accessibility driver model is available starting with Windows 8 to developers who want to provide mirror driver capabilities in assistive technologies for customers with disabilities or impairments. To learn more about this special driver model, please contact [email protected].

A remote display driver model that is based on the mirror driver architecture can also run starting with Windows 8. For more information, see Remote Display Drivers.