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 1 commit 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. |
aa65ec6 to
e3ebaf8
Compare
The gfxstream 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 that each can be dropped on its own, ordered the way they are expected to leave: the three that have already landed first, then the six that are still under review. Merged upstream, and here only because the pin predates them: - virtgpu_kumquat_finish accepts a null device. A failed init leaves the caller's pointer null, and Box::from_raw on null raises a non-unwinding panic that aborts the process and destroys the error explaining the failure. - The Vulkan mapper imports host memory through an fd on Apple as well. It was compiled for Linux only, so the kumquat guest platform did not build. - LINUX_GUEST_BUILD is no longer defined on Apple. It was defined for every host that is not Windows or Fuchsia, and the code it guards uses dma-buf imports and DRM format modifiers declared only on Linux and Android. Still under review, and what makes vulkaninfo work: - VK_ANDROID_native_buffer is undefined on Apple. cerealgenerator already does that for the guest builds that do not implement it, so that the dispatch table does not define entrypoints the generated header leaves undeclared; Apple was missing from the list. - rustix gains the features an Apple sys backend needs. - mach2 gains a wrap. The Mach IPC calls have no Rust bindings in tree, and libc stops at mach_port_t. - mesa3d_util gains a macOS sys layer. It resolved to the stub backend, whose entry points are unimplemented, so the kumquat server exited with MesaError(Unsupported) as soon as it opened a tube. It is built on Mach IPC: a tube is a port, so mach_msg gives message boundaries that SOCK_SEQPACKET would not and a port descriptor can carry an IOSurface that a socket could not; two processes meet through the bootstrap server rather than a socket path, so nothing touches /tmp; an event is a port, signalled by a send and waited on by a receive; and the wait context is kqueue with EVFILT_MACHPORT. macOS also has no memfd_create, so shared memory is shm_open followed by shm_unlink, and no /proc/self/fd, so descriptors are classified from their stat type and open flags. - The guest uses kumquat as its virtgpu backend on Apple, which has no DRM subsystem and so no native backend to fall back to. - The Vulkan driver links on Mach-O, which rejects the undefined entrypoints that ELF resolves at load time. rustix gains the shm feature flag the sys layer needs; the two crate specs are kept in step because both feed the same crate_universe extension. mach2 is a new spec, and mesa3d_util takes it only on Apple, where it is the only platform the crate builds for. Only the sys layer changes what Bazel builds today: the rustix and mach2 wrap patches are meson-only, the Mach-O patch is a link flag, and the generator one only matters when the encoder is regenerated. They are carried so that the series stays whole and drops together at the next uprev.
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.