Repository navigation
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
e7c90b3 to
d6b6deb
Compare
|
After #182 merged, I decide to update this one to update dependencies. @jmacnak @gurchetansingh from my previous inspections, looks like they are often updated in Google internal AOSP first, and then upstreamed here, which approach that you want me to follow or holding dependencies updating? Thanks. |
mesa 9ac80d5c43c has the gfxstream guest for Metal and the Darwin side of magma-gpu-rs, so no patches of ours are needed any more. Building that crate here takes mach2 on Apple, for its Mach IPC, and rustix's shm feature; the rutabaga spec names the feature too, since both resolve the one rustix crate.
rutabaga 60603af has the Darwin sys layer and kumquat's Apple shared memory, so no patches of ours are needed any more.
Generated with mesa's generate-gfxstream-vulkan.sh at the commit the pin names. Since the last regeneration the generator reports through GFXSTREAM_ERROR and GFXSTREAM_FATAL, and goldfish_vk_extension_struct_size_with_stream_features defers to goldfish_vk_extension_struct_size instead of repeating its table.
utzcoz
changed the title
The server is built here and the guest driver from a mesa checkout, so checking the macOS backend by hand is easy to get wrong: the virtualenv has to lead PATH before meson setup, bazel does not refetch mesa when a patch's contents change, and the host renderer needs a Vulkan ICD of its own. Script it, and assert rather than print: every client has to come back through gfxstream, the server has to survive all of them, and the bootstrap namespace has to be empty at the end. The header also spells out the server and client environment for running a single program by hand. Not wired into presubmit: the macOS runner has no graphics driver to render with.
|
Looks good, but let's wait until gfxstream is updated from an internal merge so there's no codegen changes (the plan is to Github first development very soon though once certain logistical hurdles are sorted out). |
…EMU) build-gfxstream.sh builds the Mac side of the gfxstream graphics stack, Google's Android-emulator renderer, as the first step toward replacing virglrenderer: - the gfxstream host renderer with Bazel, from the macOS work in google/gfxstream#168 (utzcoz/gfxstream e9eed53), optimized; - rutabaga_gfx (magma-gpu 60603af) with the gfxstream feature, the C library QEMU drives it through, plus a pkg-config file for QEMU; - UTM's QEMU 10.0.12 as a shared library (what qemu-interop loads) with HVF, SPICE GL, virglrenderer and the virtio-gpu-rutabaga device; apple-gfx (removed SDK APIs) and GTK (clashes with the library build) are left out, and GL_TEXTURE_RECTANGLE_ANGLE is defined (0x84F5) for UTM's SPICE GL code. gfxstream finds the Vulkan loader next to the launcher, so UTM's is linked into $WORK/host/lib64/vulkan. Checked: with VM_QEMU_LIBRARY pointing at the new QEMU and -device virtio-gpu-rutabaga-pci,gfxstream-vulkan=on, gfxstream loads MoltenVK 1.4.2, selects the Apple M3 Pro, creates its device with Metal external memory and starts its Vulkan compositor. No guest side yet; install.sh and the app are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…EMU) build-gfxstream.sh builds the Mac side of the gfxstream graphics stack, Google's Android-emulator renderer, as the first step toward replacing virglrenderer: - the gfxstream host renderer with Bazel, from the macOS work in google/gfxstream#168 (utzcoz/gfxstream e9eed53), optimized; - rutabaga_gfx (magma-gpu 60603af) with the gfxstream feature, the C library QEMU drives it through, plus a pkg-config file for QEMU; - UTM's QEMU 10.0.12 as a shared library (what qemu-interop loads) with HVF, SPICE GL, virglrenderer and the virtio-gpu-rutabaga device; apple-gfx (removed SDK APIs) and GTK (clashes with the library build) are left out, and GL_TEXTURE_RECTANGLE_ANGLE is defined (0x84F5) for UTM's SPICE GL code. gfxstream finds the Vulkan loader next to the launcher, so UTM's is linked into $WORK/host/lib64/vulkan. Checked: with VM_QEMU_LIBRARY pointing at the new QEMU and -device virtio-gpu-rutabaga-pci,gfxstream-vulkan=on, gfxstream loads MoltenVK 1.4.2, selects the Apple M3 Pro, creates its device with Metal external memory and starts its Vulkan compositor. No guest side yet; install.sh and the app are unchanged.
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.The gfxstream guest for Metal and the Darwin side of magma-gpu-rs are in mesa now, and the Darwin sys layer and kumquat's Apple shared memory are in rutabaga. Moving both pins to current upstream lets the guest driver reach a kumquat server on macOS with no patches of ours.
The two pins move together: new rutabaga needs new mesa crate, so the server does not build with only one of them.
Checked on an M2 Pro with KosmicKrisp and MoltenVK hosts: vulkaninfo and vkcube through the guest driver, the dEQP-VK smoke and wsi.metal tests, api.invariance, a' samples, all passing.