Test: Vulkan on RTX 20 series cards

A test build for #187, not a release. It's the app and the daemon from the branch vulkan-depth-formats at 6340773, which is main with two changes, built the same way as 0.5.2's.

The first is the one from test-vulkan-depth-1: NVIDIA's Vulkan driver keeps a depth image in a heap of plain memory, and the daemon now maps those pages as depth. The second is new: on an RTX 2080 the driver gives the depth image a format the daemon didn't know as depth, so the first change alone would not have helped there. The GPU faults on plain pages under a depth image, which is Vulkan freezing in GravityMark.

It goes on top of an install of 0.5.2. Nothing points at it, and the next update replaces it.

No card has run this build yet.

sha256 3f7aae66e0695d0ce8ccfae260031bd4a5be9cdb176c7c50cc4d6d0fa973ea1d

Its source is that commit.

Test: Blender with Vulkan, OpenCL and CUDA on NVIDIA cards

A test build for #183, not a release. It's the app and the daemon from the branch issue-183-both at 2385fd2, which is main with two changes, built the same way as 0.5.2's.

The first is the one from test-vulkan-depth-1: NVIDIA's Vulkan driver keeps a depth image in a heap of plain memory, and the daemon now maps those pages as depth. That is the black window in Blender with the Vulkan backend on RTX 20, 30 and 40 series cards.

The second is new. NVIDIA's driver in the guest is told the card sits at the host's PCI bus and slot, while Windows in the guest has it at another place. With GUESTHOUSE_GUEST_PCI set, the driver hears the guest's place. That may be why OpenCL crashes and CUDA can't share a buffer with OpenGL, but it's a guess, and this build is how I find out.

It goes on top of an install of 0.5.2. Nothing points at it, and the next update replaces it.

No card has run this build yet.

sha256 424a08c3ab61a40097fc33a77d59c90621960e6daf107da7bf64ce8f7bbb5c72

Its source is that commit.

Test: OpenCL and CUDA with OpenGL on NVIDIA cards

A test build for #183, not a release. It's the app and the daemon from the branch guest-pci-address at c364a19, which is main with one change, built the same way as 0.5.2's. NVIDIA's driver in the guest is told the card sits at the host's PCI bus and slot, while Windows in the guest has it at another place. With GUESTHOUSE_GUEST_PCI set, the driver hears the guest's place. That may be why OpenCL crashes and CUDA can't share a buffer with OpenGL, but it's a guess, and this build is how I find out. It goes on top of an install of 0.5.2. Nothing points at it, and the next update replaces it.

No card has run this build yet.

sha256 7b621a9c9986c92dd596ecfc1906e3c43ff4e1eb732b9b5f02ef602ea380eb7a

Its source is that commit.

0.5.2

Mostly speed on AMD cards, and a few fixes from this week's reports.

To update, use the button in the app, or run ~/.local/lib/guesthouse/current/install.sh --update. Your machines, disks and settings stay as they are. To install, use the line in the README.

AMD:

• Windows is a good deal faster on discrete cards. The card now writes the guest's fence itself, so the daemon no longer waits for each run to finish (#118, #171). And guest memory goes to the card as a dma-buf, pinned once, so the kernel no longer walks all of it on every submission (#118, #188). On an RX 9070 XT, Superposition at 720p Low went from 21,920 to 36,903 (thanks @Short3D).
• The second part needs /dev/udmabuf, and your user has to be allowed to open it. On many distros that means being in the kvm group. Without it everything still works, at the old speed. The app's checks and the installer tell you when it can't be opened (#191).
• On RX 9000 cards a program that reads its picture back every frame was very slow, as 3ds Max with three viewports was at about 5 fps (#182, #184, thanks @Short3D).

NVIDIA:

• RTX 20 series cards that report SM version 0x705, like the RTX 2080, were refused at start. They have their shader set now (#187, #189, thanks @asarychev). The reporter ran an RTX 2080 with a patch of their own. This build hasn't run on one yet.
• nvidia-smi in the guest shows the right figure for memory used (#177).

Both:

• The viewer shows each frame one screen refresh sooner: 16.5 ms less delay at 60 Hz, about 4 ms at 240 Hz (#180).

Install:

• The installer stopped on openSUSE, asking for a package that doesn't exist there (#179).

I have no GPU PC this week, so I built and install-tested this release but didn't start a machine on it myself. The AMD fixes were each run by their reporter on their own card.

Test: Blender with Vulkan on RTX 20, 30 and 40 series

A test build for #183, not a release. It's the app and the daemon from the branch vulkan-depth-heap at b8d424c, which is main with one change, built the same way as 0.5.1's. NVIDIA's Vulkan driver keeps a depth image in a heap of plain memory, and the daemon mapped those pages as plain. On RTX 20, 30 and 40 series cards the GPU faults on that, which is the black window in Blender with the Vulkan backend. Now the pages are mapped as depth. It goes on top of an install of 0.5.1. Nothing points at it, and the next update replaces it.

No card has run this build yet.

sha256 6cc3a1bff281effab0a82936e1d464bbef4a4905b5c45e7d2c344e6188a04b54

Its source is that commit.

Test: RTX 20 series cards that report SM 0x705

A test build for #187, not a release. It's the app and the daemon from the branch turing-sm-705 at 82e99ca, which is main at 9a68f9f and one commit, built the same way as 0.5.1's. An RTX 2080 reports an SM version the daemon had no shader set for, so it refused the card. This build has the row, with the set NVIDIA's Windows driver gives that version. It also has what went into main for 20 and 16 series cards since 0.5.1. It goes on top of an install of 0.5.1. Nothing points at it, and the next update replaces it.

No card has run this build yet.

sha256 cb7692892c3fd411aef112914f7b27134b2c26fb4a366bb7eca9e67946769c2e

Its source is that commit.

Test: guest memory as a dma-buf on AMD cards, second build

A test build for #118, not a release. It's the app and the daemon from the branch amd-guest-pages-jail at 733e47d, which is main at 9a68f9f and two commits, built the same way as 0.5.1's. The first build never used /dev/udmabuf: the daemon's own jail didn't let it open the device, so it always fell back to the old way. This one lets it through. It also has the faster readback on RX 9000 series cards from #184. It goes on top of an install of 0.5.1. Nothing points at it, and the next update replaces it.

No card has run this build yet.

sha256 c46769427ae705681d6280fa63368c3d83567ffd9ab8a525f7ca84ddd44a3947

Its source is that commit.

0.5.1

Fixes from this week's reports. Each one was run by the person who reported it, on their own card.

To update, use the button in the app, or run ~/.local/lib/guesthouse/current/install.sh --update. Your machines, disks and settings stay as they are. To install, use the line in the README.

NVIDIA:

• A DirectX 12 game could crash the GPU work with a depth buffer fault, as Forza Horizon 4 did on a GTX 1660 SUPER (#141, #165, thanks @BestRazer).
• A game that sent a very long batch of commands lost the GPU when its command ring grew (#164, #167, thanks @BestRazer).
• The same games ran in slow bursts, as the daemon paused them for 100 ms at every very large batch (#164, #167).
• The verbose log has times now, and says when a queue is held back and for how long.

AMD:

• On RX 9000 cards a program that hands its picture over as a copy showed nothing, as the 3ds Max viewport did on an RX 9070 XT (#166, #168, thanks @Short3D).

Test: slow readback on RX 9000 series cards

A test build for #182, not a release. It's the app and the daemon from the branch gfx12-linear-copy at e325ade, which is main with one change, built the same way as 0.5.1's. On RX 9000 series cards, when a program read back a new buffer for the first time, the daemon moved it out of video memory with the CPU, which is slow. 3ds Max with three viewports does that for every frame. Now the card moves it, as it already did on RX 6000 and 7000. It goes on top of an install of 0.5.1. Nothing points at it, and the next update replaces it.

No card has run this build yet.

sha256 01e47ecdc076eb5a2ae327c5f544774bc98433fe6d4b55132558e40ee9ecb0b8

Its source is that commit.

Test: speed on AMD cards, second build

A test build for #118, not a release. It's the app and the daemon from main at 565c156, built the same way as 0.5.1's. On AMD cards the daemon waited for each piece of the guest's work to finish before it told the guest. Since #171 the card writes that itself, on RX 6000, 7000 and 9000 series cards, and the daemon doesn't wait. It goes on top of an install of 0.5.1. Nothing points at it, and the next update replaces it.

An RX 9070 XT ran the build before this one, which lacked one small fix. No RX 6000 or 7000 card has run it yet.

sha256 3fbc53ad03940a5824049152a0aaa106c998924299e91402810a0c738d5e29ed

Its source is that commit.