I'm adding features to VKMS! What would you like to see?

[Pekka Paalanen]

On Thu, 28 Jul 2022 14:54:31 -0400
Jim Shargo <jshargo at chromium.org> wrote:

> Hi Wayland folks!
> 
> TL;DR: I'm working on extending VKMS and wanted feedback from other
> compositor/wayland devs.

Hi Jim!

> // Background
> 
> I work on the ChromeOS compositor, and recently I've been doing a
> bunch of stuff to improve our testing setup. At the moment, my main
> focus is improving our ability to write integration tests against
> DRM/KMS.
> 
> It's pretty tricky to get right. Working with mocks of DRM loses all
> the useful helpers that live within the kernel, which would need to be
> rewritten (and kept up-to-date) in userspace. Stuff like writeback
> support would be even harder.
> 
> Earlier this year, VKMS came up as a potential solution. I was happy
> to see that Weston is already using it. I've started thinking about
> what features from the wild we'd need, and started digging into the
> code.
> 
> // Current Status
> 
> I recently sent out my first patchset, which will let userspace build
> their own DRM drivers with ConfigFS. This implicitly adds support for
> multi-display setups which were impossible to test before. This also
> allows for multiple virtual DRM drivers to be created and used at the
> same time, which may increase test parallelism? Haven't tried it yet.
> 
> v1 patchset: https://patchwork.kernel.org/project/dri-devel/list/?series=662676
> cover letter: https://lists.freedesktop.org/archives/dri-devel/2022-July/365647.html

Personally I've disabled mail deliver from dri-devel list in order to
focus my time better, but please do CC me on VKMS things.

The ConfigFS UAPI looked nice to me, not having any contact with
ConfigFS before.

> // Rough Plans
> 
> The big features I want to target with this work are:
>   - Multi-display and movable planes. This is mostly covered by the
> ConfigFS changes.

Yes! \o/

>   - Hot plugging.

Yes! \o/

>   - Color, color management and HDR. Loads of new formats, support for
> color properties not currently implemented. Making sure writeback
> buffers are useful for this.

Yes! \o/

Please check VKMS patches from Igor Torrente:
https://lore.kernel.org/dri-devel/20220614000226.93297-1-igormtorrente@gmail.com/

They add some new format support with a new compositing algorithm.

>   - Improve IGT testing for VKMS (for new features and existing skipped tests)

Awesome, though not directly benefiting me/Weston. Making sure all
drivers implement the KMS properties the same way is crucial.

> 
> // Questions
> 
>   - What VKMS features could help your testing the most?

For Weston, hotplug might be the immediate low-hanging fruit. Multiple
planes with writeback. Multiple outputs with different "hardware"
timing cycles. Different plane z-order and format restrictions.
Anything really.

Also, getting feedback on HDMI/DP infoframe contents. That's going to
become especially important with HDR monitors, and while there is not
much to test (the driver and hardware are supposed to be just
pass-through for metadata), it would be nice to check userspace is
using the KMS UAPI right.

>   - How much do you care about writeback buffer support vs CRC checks
> in tests atm?

It is much cleaner to use writeback for Weston KMS tests than it would
be to use CRC checks. In fact, once we get to high precision pixel
formats or testing things like LUT KMS elements, I think CRC checks
will become useless.

We cannot store CRC values because they are driver and hardware
dependent, so every test would need to realize the same scene twice:
once with the bells and whistles, and once without to generate the
reference CRC. That gets us the CRC computation itself, but it does not
get us the KMS color pipeline. The KMS pipeline might be rounding
values differently than what we do for the reference image. Even simple
alpha-blending might be untestable with CRC because of that.
CRC cannot allow any tolerance in the pixel values.

Being able to use and control the per-pixel error tolerance is going to
be absolutely crucial, so writeback is the only way.

>   - What kinds of bugs do you get around DRM/KMS?

I guess things we did not expect more than mistakes in Weston, or
situations we don't handle:
- link-status
- temporary EBUSY https://gitlab.freedesktop.org/wayland/weston/-/issues/435
- needing to downgrade the framebuffer format modifier on an already
  used CRTC in order to be able to light up another CRTC (whole-device
  or global bandwidth limitations)
- other KMS clients leaving the KMS in unexpected state

>   - Any thoughts in general?

Awesome! Woo! \o/

I do hope you find reviewers.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20220729/ef57f7ba/attachment.sig>