Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation

[Akihiko Odaki <akihiko.odaki@daynix.com>]

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