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 2 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
35c4c0b to
1692f1e
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 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 patch comes before the sys layer because the sys layer is written against it: an event is now an explicit signaller and waiter rather than one object that clones, which is what a Mach port needs, since only the end holding the receive right can wait. Only the sys layer changes what Bazel builds; the others 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.
mesa3d_util replaces Event with create_event_pair(), so rutabaga's own code no longer compiles against it: the kumquat fence path and cross_domain both build events and clone them. Carry the change until it lands upstream. The kumquat server keeps the signaller and sends the waiter to the guest, and cross_domain hands its worker thread the waiting halves. 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.
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.