On 2/6/25 08:41, Akihiko Odaki wrote: > On 2025/02/06 2:40, Dmitry Osipenko wrote: >> On 2/3/25 08:31, Akihiko Odaki wrote: >> ... >>>> Requirements don't vary much. For example virglrenderer minigbm support >>>> is mandatory for crosvm, while for QEMU it's not. >>> >>> Is that true? It seems that virglrenderer uses builds without minigbm >>> support to run tests on GitLab CI. >> >> CI is running in a headless mode using software renderer. For a >> full-featured crosvm support running on a baremetal, minigbm should be >> needed, along with other downstream features. > > That makes sense. > > Based on your input, for QEMU, I don't think we need a separate > documentation to describe libvirglrenderer's build flags though crosvm > should have some documentation saying it requires minigbm. > >> >>> Anyway, if there is any variance in the build procedure, that may >>> justify having a separate build instruction in QEMU tree to avoid >>> confusion. Otherwise, it's better to have a documentation shared with >>> other VMMs. >>> >>>> >>>>> I'm not entirely sure the documentation will stay as is for that long. >>>>> The requirements of Intel native context refer to merge requests that >>>>> can be merged sooner or later. Asahi may need more updates if you >>>>> document it too because its DRM ABI is still unstable. >>>> >>>> The unstable parts of course will need to be updated sooner, but the >>>> stable should be solid for years. I expect that about a year later >>>> requirements will need to be revisited. >>>> >>> >>> It will be some burden in the future. Now you are adding this >>> documentation just for QEMU, but crosvm and libkrun may gain similar >>> documentation. The DRM native context support for Intel and Asahi is in >>> development, and I guess nvk will support it someday. >>> >>> So, a very rough estimation of future documentation updates will be: >>> (number of VMMs) * (number of DRM native contexts in development) >>> = 3 * 3 >>> = 9 >>> >>> That's manageable but suboptimal. >> >> I don't mind deferring the doc addition if that's preferred. Either way >> is fine with me. Yet it's better to have doc than not. > > My suggestion is not to defer the addition, but to add it to Mesa, which > does not require deferring. > >> >> In my view crosvm and libkrun exist separately from QEMU, they serve a >> different purpose. Majority of QEMU users likely never heard about those >> other VMMs. A unified doc won't be a worthwhile effort, IMO. >> > > When evaluating the utility of a unified documentation, Whether the > majority of Mesa/Virgl users care VMMs other than QEMU matters more. And > I think it is true; libkrun and crosvm are excellent options for > graphics-accelerated VMs. > > If we have a unified documentation, any VM can point to it for the build > instruction of Mesa and virglrenderer. Once that's done, QEMU users who > want graphics acceleration can take the following steps: > 1. See docs/system/devices/virtio-gpu.rst > 2. Figure out that they need Mesa and virglrenderer > 3. Click the link to the unified documentation > 4. Build Mesa and virglrenderer accordingly > > No other VMMs will bother them in this procedure.
Will see. For the starter, adding example build flags to QEMU doesn't hurt, it's a very minimal information. Later on, if and when all relevant Mesa/virglrenderer doc pages will appear, it won't be a problem replace QEMU flags with the links. Please let's do it step-by-step, one step at a time :) -- Best regards, Dmitry
