Return to Level1Techs.com

A little teaser of what is to come :)


#528

Again, its astonishing how the development of desktop virtualization has speed up in the last two years and this mostly in the open source world. We can hear the grass growing…

May I ask, when you first started to experiment with accessing the guest gpus framebuffer?


#529

on archlinux it WORKS…
needed the extra packages sd2 sdl2_ttf spice_protocol

also i did not realize for a bit that the ivshmem pid and socket file are accessed by the kvm user brainlag in action
fix was simple sudo chmod o+rw "/tmp/ivshmem*"

but now it WOOORKS

thank you soooo much

PS: my system is still TR 1950x and dual vega … so i am assuming that is what causes my low performance and fps on the client (reaching from 2-30) with looking-glass-client -ka

lookig forward to get that fixed as well … hopefully soon


#530

About a week before I ran into the NPT problem.

https://lists.linuxfoundation.org/pipermail/iommu/2017-October/024816.html


#531

So you build this from the ground up to todays stage in only two months, Impressive!


#532

Yep sent Geoff my Vega. It’s something in Vegas pipeline only because amdgpu.dc =1 works fine w/fury but not Vega for whatever reason on kernel 4.15

Still working with MSI on TR pcie fixes. Lulz.


#533

This brings up an interesting point. QEMU by default creates it’s own user to run stuff off of and set it’s own permissions. I think the fix should be as simple as telling people to modify their QEMU config to run off of their own user account and group instead.


#534

And thank you very much! been keeping a keen eye out for the post man!

Man alive Vulkan needs a TON of initialization code, I am only I think 40-50% done and we are at 650 lines and counting.


#535

Vulkan will be very handy as it is a lower level API than OpenGL. Combine that with the Nvidia capture API and those latencies would be insanely low.


#536

Yeah, I’d say so… after a casual look over the API I think I can tell Vulcan to take the shared memory directly, removing one of the two CPU based memory copies we currently need to do with OpenGL.

It just takes a TON of code to just get it all setup…

We can also support Wayland, etc with this.


#537

On GNOME 3 on Fedora, Wayland support will be really handy.

Though that will require an AMD card as the host. Nvidia and Wayland aren’t friends yet.


#538

#539

Yeah, see? and the community’s hostile stance towards “their way or the highway” ain’t helping things neither. We’re at a standstill.


#540

Well well well… This just got announced for people using Linux as the guest OS… Exciting times indeed.

https://www.phoronix.com/scan.php?page=news_item&px=VirtIO-DRM-Window-Server


#541

That’s cool… I will be able to play my Linux games without dualbooting finally… oh wait. :stuck_out_tongue:


#542

Clone a Linux Guest and have LAN multiplayer on one screen.


#543

The trick will be to run Linux in a Nested Hyper-V VM on Windows running on KVM… and then in the nested Linux run Dosbox…

Inception!


#544

Believe it or not, with Rocket League, a game that is truly multiplatform, one Steam account per OS works in this fashion.

If you have Wine, once they get D3D11 to a usable state in Vulkan, Windows VM and Wine running Overwatch at the same time sounds cool. (it has to be Vulkan cause the D3D11 to OpenGL that Wine staging currently has is extremely taxing on the CPU. You basically need Threadripper for decent performance, assuming the OpenGL renderer can multithread.)


#545

You’re funny. I like you.

But on a serious note, this method would probably be easier to do than my other idea of creating a nested Wayland session for split-screen:


#546

CRAP! Looking Glass is on the top trending list of projects on GitHub!

Its number one for projects written in C


#547

I wouldn’t expect any less. This project is pretty amazing!