Run gfxstream end to end on macOS, guest to host over kumquat - #168
Run gfxstream end to end on macOS, guest to host over kumquat#168utzcoz wants to merge 5 commits into
Conversation
|
For dependencies like molten-vk and vulkan-loader, what's the best practice of gfxstream of using them? Installing outer dependency or submodule integration under third_party. @jmacnak @gurchetansingh PTAL. |
|
I don't see any virtgpu_kumquat changes in this MR, perhaps you missed them. We probably want the changes to land in Mesa3D first, and then figure out a way to bring-them back here for the end2end tests. I think you should try to get Kumquat working without Bazel build first, just with meson (it's simpler). For example, on Linux, we are able to run gfxstream-vulkan (not gfxstream GLES, which is being phased out anyways) over Kumquat just using the meson build: https://github.com/magma-gpu/rutabaga_gfx/#build-gfxstream-guest For MacOS, you will have fun challenges around:
That said, I do think there's some emulated copy mode gfxstream-vulkan uses on iOS using VkFlushMemory ranges: you'll have to check. But zero copy is the ideal. |
Got it. After rebasing, I think this PR can upstream gfxstream first without third_party patches. Now I will switch to upstream Mesa3D related patches first, and pending this one. Thanks for reviewing. |
|
Added mesa related patches changes to this branch, and also pending for this PR and start to upstream work. |
|
The first serial is here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43534. cc @gurchetansingh . |
|
For For Also, remember not to worry too much about emulated Android, GLES or Bazel builds. If you get VulkanInfo working via Kumquat on MacOS, that's a win. We can think about vkcube after that. |
No problem. I can split patches and use this PR to track what I have done, and upstream smaller patches one by one for small goal. If there are other patches that can be sent to GitHub gfxstream, I also can split them and use other PRs. |
75c5d90 to
5762739
Compare
|
The second serial: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43591, and we can run vulkaninfo to retrieve driver information. I also switch to add mesa patches for this PR for easier testing for Mesa changes for milestones one by one. |
e3ebaf8 to
2209c7b
Compare
1692f1e to
e7c90b3
Compare
The guest driver and the kumquat server both live on mesa, and mesa's macOS support is not all upstream yet. Carry it as downstream patches, one file per upstream commit so each can be dropped on its own, ordered the way they are expected to leave. What is left is what is still under review: the VK_ANDROID_native_buffer undef, the rustix and mach2 wraps, the event pair API, the descriptors Tube::send takes, the Darwin sys layer, the guest virtio-gpu stub, and the Mach-O link fix. The three that had merged upstream are gone, since the pin now carries them. The pin also moved the crate to src/virtio/magma-gpu-rs, so these are plain format-patch output of the mesa commits rather than the same change rewritten for the old src/util/rust layout and names. The event pair and Tube::send patches come before the sys layer because the sys layer is written against them: an event is now an explicit signaller and waiter rather than one object that clones, and a send takes the descriptors rather than borrowing them. Both are what a Mach port needs, since only the end holding the receive right can wait, and handing that end to a peer moves it away. Those two and the sys layer are what Bazel builds; the rest are meson or link flags, carried so the series stays whole and drops together at the next uprev. mach2 is a new crate spec, taken only on Apple.
rutabaga's own code is built against mesa3d_util, so it follows the two API changes the guest driver needs. The event pair change is upstream, so the pin moves onto it; Tube::send taking the descriptors rather than borrowing them is still under review, so it is carried as a patch until it lands. Only rutabaga's own sources are patched. Bazel builds the server against @mesa//:mesa_rust_util rather than the vendored third_party/mesa3d copy, so that copy travels in the rutabaga_gfx change instead. rustix also gains shm, which the Darwin backend needs.
… Apple vkMapMemory hung the guest: the host cannot export device memory on Metal and stopped without replying. With system blobs the host backs host visible memory with shared memory the guest already knows how to map.
With system blobs, host visible memory is shared memory imported as a host pointer, and Metal cannot bind a tiled image to that. A device that reports one unified memory type, as kosmickrisp does, then has nowhere to put an image, and kk_image_plane_bind asserts on the first one. Add a guest only type in that case: device local, first in the list so that it is what an image is given, allocating from the same host type without host visible emulation. Memory requirements include it wherever the host type is allowed. MoltenVK reports a device local only type of its own, so nothing changes there.
System blob memory is named shared-memory-vk-N with a per process counter and opened without O_EXCL. A server that is killed leaves its objects behind, the next one reuses the names, and on macOS an object that already has a size cannot be resized: ftruncate fails with EINVAL and vkAllocateMemory fails. Put the pid in the name, and on Apple unlink the object as soon as it exists; the descriptor keeps it alive and is what the guest is handed.
e7c90b3 to
d6b6deb
Compare
2 participants
Follow-up to the macOS host and GLES test PR. That one made the host side testable on macOS; this one adds the guest side, so the full guest-to-host path runs: the gfxstream guest driver talks to a kumquat server over the macOS IPC layer, and the host renders with ANGLE on MoltenVK.
Unlike the previous PR, this one does carry third_party/mesa patches.