Well at least we have an answer and official confirmation that this reset method will put the card into a useful state. I am going to get some sleep now and will try to figure this out over the next few days. It doesn’t look like too much to implement, just need to reverse engineer how it currently operates to cut out all the unnecessary stuff.
One thing to note however, VEGA12 will have the exact same problem, it’s reset the same way. Thankfully the reset method is identical so this could be applied to that card also.
Is it possible modifying the AMDGPU firmware process or patching the stock firmware device files might help with other cards? it seems like you can force your initramfs to incorporate different files and change the PSP loading process with the fw_load_type amdpu module parameter.
It is not possible to modify the firmware as it is signed. As for a AtomBIOS shim, that is possible, but it very likely will not help with fixing cards as the AtomBIOS is designed for the low level early initalization before the firmware takes over, which is where the problems will lie.
To be honest at the moment this is not my goal though, if I am so inclined I may look later but the goal to achieve here is a fixed VEGA10 and VEGA12 series reset.
This morning I have managed to gather all the information together needed to issue the PSP mode3 reset, including a way to detect if the PSP microcode has already been loaded into the GPU. This is great because now (in theory) instead of needing to load the microcode, simply detecting if it’s already loaded will tell us if the card needs a reset.
However, even if the microcode does still require loading it is not very hard to add this, but I am not sure that Linus will like firmware loading code to enter a PCI Quirk, I know personally it doesn’t “feel” right.
IIRC you can actually patch the kernel to load something else before init, basically point the driver at a romfile, because the psp only checks what’s on the card. I’ve sent out an email to wolf0 to see if she’ll give me her method for doing so. I know for a fact it works around the PSP signing check, as i’ve seen mining rigs set up with completely off-spec and unsigned bioses on vega running happily.
error: Failed to start domain win10lab
error: internal error: process exited while connecting to monitor: 2018-08-09T12:56:18.531699Z qemu-system-x86_64: -object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/looking-glass,size=33554432,share=yes: can’t open backing store /dev/shm/looking-glass for guest RAM: Permission denied
maestro@juggler:~$ ls -l /dev/shm/looking-glass
-rw-rw---- 1 maestro kvm 0 août 9 11:50 /dev/shm/looking-glass
The problem was related to AppArmor: thanks Ubuntu!
The following commands solved both of my problems (starting looking-glass-client and the VM itself):
I noticed that Looking Glass on GNOME on Wayland has some performance issues. I cannot sustain the 144 frames, only around 120.
If GNOME on Xorg is used Looking Glass seems to be able to sustain 144 frames.
Not sure if the problem is with GNOME or Wayland. The only other Wayland desktop environment I know of is Sway but it does not support 144 Hz refresh rate yet so I won’t be able to test.
I can’t seem to get the keyboard and mouse to work. I get video and tried scroll lock but can’t seem to capture them. Did I miss something? I am running it with -s because I get an error below.
[I] main.c:692 | run | Looking Glass ()
[I] main.c:693 | run | Locking Method: Atomic
[I] main.c:686 | try_renderer | Using Renderer: OpenGL
[I] main.c:775 | run | Using: OpenGL
[I] spice.c:159 | spice_connect | Remote: 127.0.0.1:5900
[E] spice.c:562 | spice_connect_channel | socket connect failure
[E] spice.c:167 | spice_connect | connect main channel failed
[E] main.c:868 | run | Failed to connect to spice server
Update 1: After adding display spice to the VM I am able to run it with out -s and capture keyboard and mouse. Issue now is the mouse does not work right (right click and mouse jumps). I thought Display Spice is not needed?
Update 2: I add a spice channel to VM and now looking glass client works without -s and without Spice display. Still not able to get mouse and keyboard to capture.
Make sure you do not have a “Tablet” pointing device attached, Looking Glass does not work with absolute positioning devices as they do not work with FPS games.
If I unplug the HDMI cable, I loose the mouse pointer. I press scroll lock, I see the event capture but still no mouse. Also, I have to add Display Spice or I get can connect to Spice Server. Could this be what’s causing the issue? If it is, how do I avoid the Spice server error?
This is expected, your GPU still needs to see a monitor attached. You’re not actually loosing the mouse, you’re loosing all video and the stream freezes.
Correct, when using libvirt you must have a Spice display attached. If using QEMU direct (without libvirt) you can just specify a spice server without a display.
Soooo… With the embargo lift today, it’s looking like the 2990WX is not going to be good for Looking Glass. Heavy memory copy performance penalties in it’s UMA only state.
If you want Threadripper 2, wait till August 31st for the 2950x.
Or get a low-end Epyc instead.
Side-note: do they work in X399 boards since it’s the same socket?
/edit seems nope.
From what I’ve seen that penalty is mainly if you’re doing it on one of the 2 dies that are not directly attached to the RAM, it should be fine if you pin the process to one of the two dies with the active IMC.
I’ve just finished up setting up my Ubuntu 18.04 LTS machine with a Windows 10 Guest VM that uses Looking Glass, and I’ve written down in extreme detail all of the problems I ran into while attempting to do so, here: