Re: [PATCH] drm/vkms: Extend todo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 03, 2018 at 09:57:15AM -0300, Rodrigo Siqueira wrote:
> Hi,
> 
> I just added some minor reviews below.
> 
> Also, did you give up to add the eBPF task? 

I forgot to add that. Will fix.

> 
> 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@xxxxxxxxx>
> > Cc: Gustavo Padovan <gustavo@xxxxxxxxxxx>
> > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> > Cc: Sean Paul <sean@xxxxxxxxxx>
> > Cc: Haneen Mohammed <hamohammed.sa@xxxxxxxxx>
> > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@xxxxxxxxx>
> > ---
> >  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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux