Typed up all the items Rodrigo capture at the vkms workshop at xdc2018:
https://etherpad.net/p/vkms_todo
v2: Review from Rodrigo. - Add eBPF for atomic check, I forgot it. - Improve spelling.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com Cc: Gustavo Padovan gustavo@padovan.org Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Haneen Mohammed hamohammed.sa@gmail.com Cc: Rodrigo Siqueira rodrigosiqueiramelo@gmail.com --- Documentation/gpu/vkms.rst | 101 ++++++++++++++++++++++++++++++++++++- 1 file changed, 99 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 0a6ea6216e41..7dfc349a4508 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,8 +10,8 @@ TODO ====
-CRC API -------- +CRC API Improvements +--------------------
- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
@@ -22,3 +22,100 @@ CRC API
- Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes). + +Vblank issues +------------- + +Some IGT test cases are failing. Need to analyze why and fix the issues: + +- plain-flip-fb-recreate +- plain-flip-ts-check +- flip-vs-blocking-wf-vblank +- plain-flip-fb-recreate-interruptible +- flip-vs-wf_vblank-interruptible + +Runtime Configuration +--------------------- + +We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases: + +- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of + compositors). + +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of + them first). + +- Change output configuration: Plug/unplug screens, change EDID, allow changing + the refresh rate. + +The currently proposed solution is to expose vkms configuration through +configfs. All existing module options should be supported through configfs too. + +Add Plane Features +------------------ + +There's lots of plane features we could add support for: + +- Real overlay planes, not just cursor. + +- Full alpha blending on all planes. + +- Rotation, scaling. + +- Additional buffer formats, especially YUV formats for video like NV12. + Low/high bpp RGB formats would also be interesting. + +- Async updates (currently only possible on cursor plane using the legacy cursor + api). + +For all of these, we also want to review the igt test coverage and make sure all +relevant igt testcases work on vkms. + +Writeback support +----------------- + +Currently vkms only computes a CRC for each frame. Once we have additional plane +features, we could write back the entire composited frame, and expose it as: + +- Writeback connector. This is useful for testing compositors if you don't have + hardware with writeback support. + +- As a v4l device. This is useful for debugging compositors on special vkms + configurations, so that developers see what's really going on. + +Prime Buffer Sharing +-------------------- + +We already have vgem, which is a gem driver for testing rendering, similar to +how vkms is for testing the modeset side. Adding buffer sharing support to vkms +allows us to test them together, to test synchronization and lots of other +features. Also, this allows compositors to test whether they work correctly on +SoC chips, where the display and rendering is very often split between 2 +drivers. + +Output Features +--------------- + +- Variable refresh rate/freesync support. This probably needs prime buffer + sharing support, so that we can use vgem fences to simulate rendering in + testing. Also needs support to specify the EDID. + +- Add support for link status, so that compositors can validate their runtime + fallbacks when e.g. a Display Port link goes bad. + +- All the hotplug handling describe under "Runtime Configuration". + +Atomic Check using eBPF +----------------------- + +Atomic drivers have lots of restrictions which are not exposed to userspace in +any explicit form through e.g. possible property values. Userspace can only +inquiry about these limits through the atomic IOCTL, possibly using the +TEST_ONLY flag. Trying to add configurable code for all these limits, to allow +compositors to be tested against them, would be rather futile exercise. Instead +we could add support for eBPF to validate any kind of atomic state, and +implement a library of different restrictions. + +This needs a bunch of features (plane compositing, multiple outputs, ...) +enabled already to make sense.
On 10/03, Daniel Vetter wrote:
Typed up all the items Rodrigo capture at the vkms workshop at xdc2018:
https://etherpad.net/p/vkms_todo
v2: Review from Rodrigo.
- Add eBPF for atomic check, I forgot it.
- Improve spelling.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com Cc: Gustavo Padovan gustavo@padovan.org Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Haneen Mohammed hamohammed.sa@gmail.com Cc: Rodrigo Siqueira rodrigosiqueiramelo@gmail.com
Documentation/gpu/vkms.rst | 101 ++++++++++++++++++++++++++++++++++++- 1 file changed, 99 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 0a6ea6216e41..7dfc349a4508 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,8 +10,8 @@ TODO ====
-CRC API
+CRC API Improvements +--------------------
- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
@@ -22,3 +22,100 @@ CRC API
- Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes).
+Vblank issues +-------------
+Some IGT test cases are failing. Need to analyze why and fix the issues:
+- plain-flip-fb-recreate +- plain-flip-ts-check +- flip-vs-blocking-wf-vblank +- plain-flip-fb-recreate-interruptible +- flip-vs-wf_vblank-interruptible
+Runtime Configuration +---------------------
+We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases:
+- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of
- compositors).
+- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
- them first).
+- Change output configuration: Plug/unplug screens, change EDID, allow changing
- the refresh rate.
+The currently proposed solution is to expose vkms configuration through +configfs. All existing module options should be supported through configfs too.
+Add Plane Features +------------------
+There's lots of plane features we could add support for:
+- Real overlay planes, not just cursor.
+- Full alpha blending on all planes.
+- Rotation, scaling.
+- Additional buffer formats, especially YUV formats for video like NV12.
- Low/high bpp RGB formats would also be interesting.
+- Async updates (currently only possible on cursor plane using the legacy cursor
- api).
+For all of these, we also want to review the igt test coverage and make sure all +relevant igt testcases work on vkms.
+Writeback support +-----------------
+Currently vkms only computes a CRC for each frame. Once we have additional plane +features, we could write back the entire composited frame, and expose it as:
+- Writeback connector. This is useful for testing compositors if you don't have
- hardware with writeback support.
+- As a v4l device. This is useful for debugging compositors on special vkms
- configurations, so that developers see what's really going on.
+Prime Buffer Sharing +--------------------
+We already have vgem, which is a gem driver for testing rendering, similar to +how vkms is for testing the modeset side. Adding buffer sharing support to vkms +allows us to test them together, to test synchronization and lots of other +features. Also, this allows compositors to test whether they work correctly on +SoC chips, where the display and rendering is very often split between 2 +drivers.
+Output Features +---------------
+- Variable refresh rate/freesync support. This probably needs prime buffer
- sharing support, so that we can use vgem fences to simulate rendering in
- testing. Also needs support to specify the EDID.
+- Add support for link status, so that compositors can validate their runtime
- fallbacks when e.g. a Display Port link goes bad.
+- All the hotplug handling describe under "Runtime Configuration".
+Atomic Check using eBPF +-----------------------
+Atomic drivers have lots of restrictions which are not exposed to userspace in +any explicit form through e.g. possible property values. Userspace can only +inquiry about these limits through the atomic IOCTL, possibly using the +TEST_ONLY flag. Trying to add configurable code for all these limits, to allow +compositors to be tested against them, would be rather futile exercise. Instead +we could add support for eBPF to validate any kind of atomic state, and +implement a library of different restrictions.
+This needs a bunch of features (plane compositing, multiple outputs, ...)
+enabled already to make sense.
2.19.0.rc2
Reviewed-by: Rodrigo Siqueira rodrigosiqueiramelo@gmail.com
On Wed, Oct 03, 2018 at 10:35:18AM -0300, Rodrigo Siqueira wrote:
On 10/03, Daniel Vetter wrote:
Typed up all the items Rodrigo capture at the vkms workshop at xdc2018:
https://etherpad.net/p/vkms_todo
v2: Review from Rodrigo.
- Add eBPF for atomic check, I forgot it.
- Improve spelling.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com Cc: Gustavo Padovan gustavo@padovan.org Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Haneen Mohammed hamohammed.sa@gmail.com Cc: Rodrigo Siqueira rodrigosiqueiramelo@gmail.com
Documentation/gpu/vkms.rst | 101 ++++++++++++++++++++++++++++++++++++- 1 file changed, 99 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 0a6ea6216e41..7dfc349a4508 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,8 +10,8 @@ TODO ====
-CRC API
+CRC API Improvements +--------------------
- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
@@ -22,3 +22,100 @@ CRC API
- Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes).
+Vblank issues +-------------
+Some IGT test cases are failing. Need to analyze why and fix the issues:
+- plain-flip-fb-recreate +- plain-flip-ts-check +- flip-vs-blocking-wf-vblank +- plain-flip-fb-recreate-interruptible +- flip-vs-wf_vblank-interruptible
+Runtime Configuration +---------------------
+We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases:
+- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of
- compositors).
+- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
- them first).
+- Change output configuration: Plug/unplug screens, change EDID, allow changing
- the refresh rate.
+The currently proposed solution is to expose vkms configuration through +configfs. All existing module options should be supported through configfs too.
+Add Plane Features +------------------
+There's lots of plane features we could add support for:
+- Real overlay planes, not just cursor.
+- Full alpha blending on all planes.
+- Rotation, scaling.
+- Additional buffer formats, especially YUV formats for video like NV12.
- Low/high bpp RGB formats would also be interesting.
+- Async updates (currently only possible on cursor plane using the legacy cursor
- api).
+For all of these, we also want to review the igt test coverage and make sure all +relevant igt testcases work on vkms.
+Writeback support +-----------------
+Currently vkms only computes a CRC for each frame. Once we have additional plane +features, we could write back the entire composited frame, and expose it as:
+- Writeback connector. This is useful for testing compositors if you don't have
- hardware with writeback support.
+- As a v4l device. This is useful for debugging compositors on special vkms
- configurations, so that developers see what's really going on.
+Prime Buffer Sharing +--------------------
+We already have vgem, which is a gem driver for testing rendering, similar to +how vkms is for testing the modeset side. Adding buffer sharing support to vkms +allows us to test them together, to test synchronization and lots of other +features. Also, this allows compositors to test whether they work correctly on +SoC chips, where the display and rendering is very often split between 2 +drivers.
+Output Features +---------------
+- Variable refresh rate/freesync support. This probably needs prime buffer
- sharing support, so that we can use vgem fences to simulate rendering in
- testing. Also needs support to specify the EDID.
+- Add support for link status, so that compositors can validate their runtime
- fallbacks when e.g. a Display Port link goes bad.
+- All the hotplug handling describe under "Runtime Configuration".
+Atomic Check using eBPF +-----------------------
+Atomic drivers have lots of restrictions which are not exposed to userspace in +any explicit form through e.g. possible property values. Userspace can only +inquiry about these limits through the atomic IOCTL, possibly using the +TEST_ONLY flag. Trying to add configurable code for all these limits, to allow +compositors to be tested against them, would be rather futile exercise. Instead +we could add support for eBPF to validate any kind of atomic state, and +implement a library of different restrictions.
+This needs a bunch of features (plane compositing, multiple outputs, ...)
+enabled already to make sense.
2.19.0.rc2
Reviewed-by: Rodrigo Siqueira rodrigosiqueiramelo@gmail.com
Thanks for your review, patch applied to drm-misc-next. -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Daniel Vetter -
Rodrigo Siqueira