dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sean Paul <sean@poorly.run>
Subject: Re: [PATCH] drm/vkms: Extend todo
Date: Wed, 3 Oct 2018 09:57:15 -0300	[thread overview]
Message-ID: <20181003125715.pxy4ep5oupmnsbhy@smtp.gmail.com> (raw)
In-Reply-To: <20181003123101.28784-1-daniel.vetter@ffwll.ch>

Hi,

I just added some minor reviews below.

Also, did you give up to add the eBPF task? 

Best Regards

Allow  Berkeley Packet Filter (BPF), use cases for atomic check:

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
> 
> 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 | 87 +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 85 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> index 0a6ea6216e41..80cbe0759d3c 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,86 @@ 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 testcases are failing. Need to analyze why and fix the issues:
> +

test cases

> +- 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.
> +
> +Currently proposed solution is to expose vkms configuration through configfs.
> +All existing module options should be supported through configfs too.

The currently proposed

> +Add Plane Features
> +------------------
> +
> +There's lots of plane features we could add support fort:

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.
> +

"For all of these, we"

> +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".
> -- 
> 2.19.0.rc2
> 

-- 
Rodrigo Siqueira
http://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-10-03 12:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03 12:31 [PATCH] drm/vkms: Extend todo Daniel Vetter
2018-10-03 12:57 ` Rodrigo Siqueira [this message]
2018-10-03 13:21   ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2018-10-03 13:21 Daniel Vetter
2018-10-03 13:35 ` Rodrigo Siqueira
2018-10-03 16:19   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181003125715.pxy4ep5oupmnsbhy@smtp.gmail.com \
    --to=rodrigosiqueiramelo@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox