On 2025/02/03 7:08, Dmitry Osipenko wrote:
On 1/27/25 07:57, Akihiko Odaki wrote:
On 2025/01/27 3:06, Dmitry Osipenko wrote:
On 1/21/25 07:26, Akihiko Odaki wrote:
...
I feel the dependency information for virglrenderer and Mesa are more
suited for the Mesa documentation as they are not specific to QEMU and
potentially useful also for e.g., libkrun and crosvm.
I think while everything is in so much flux it doesn't hurt to include
in our docs. I don't know if mesa currently has a dedicated page for
GPU
virtualisation.
Mesa has pages for VirGL and Venus, which can be linked from the
respective parts of this documentation. gfxstream is not documented but
I think most people will use it only for Android anyway. A documentation
for DRM native context will be a nice addition for Mesa. I will not
object if you put this information to QEMU documentation though.
Adding native context doc to Mesa indeed will be a good move, as well as
adding links to the Mesa virgl/venus pages in QEMU.
RE requirements documentation, it's also a valid point that stuff like
build flags should belong to the relevant projects. On the other hand,
it's a common headache for a newcoming people to figure everything out
from scratch and having more centralized documentation helps. The build
requirements aren't cleanly documented anywhere AFAICT, and the
requirements also differ based on VMM. I'll update and keep this patch
in v6, the requirements info should stay actual for a next couple years
IMO. Let's discuss it further in v6 if more objections will arise.
I think it's fine to require one click to reach the relevant documentation.
How do the requirements described here vary with VMM?
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.
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.
Regards,
Akihiko Odaki
