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. |
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 five 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: - The generated Vulkan entrypoints stop treating a missing prototype as an error. The dispatch table defines the four *ANDROID entrypoints whenever vk.xml has them while the header declares them only on Android, and clang applies the warning to C++ where gcc does not. - rustix gains the features an Apple sys backend needs. - 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. macOS has no SOCK_SEQPACKET, so packet tubes are framed over SOCK_STREAM; no eventfd, so an event is a self-connected SOCK_DGRAM socket that works in either direction once passed to another process; no memfd_create, so shared memory is shm_open followed by shm_unlink; no epoll, so waiting is built on kqueue; 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. Only the sys layer changes what Bazel builds today: the entrypoint, rustix-wrap and Mach-O patches are meson-only, and 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.