On Tue, Sep 11, 2018 at 02:54:22AM +0000, Satish Kumar Nagireddy wrote: > Hi Ville, Daniel, > > Thanks a lot for the reply. Some comments below. > > > -----Original Message----- > > From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel Vetter > > Sent: Monday, September 10, 2018 1:28 PM > > To: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > Cc: Satish Kumar Nagireddy <SATISHNA@xxxxxxxxxx>; dri- > > devel@xxxxxxxxxxxxxxxxxxxxx > > Subject: Re: [RFC PATCH] drm: Add new DIRTY fb flags to pass interlaced > > alternate fields > > > > On Mon, Sep 10, 2018 at 03:02:16PM +0300, Ville Syrjälä wrote: > > > On Fri, Sep 07, 2018 at 02:46:21PM -0700, Satish Kumar Nagireddy wrote: > > > > The requirement is to render interlaced alternate buffers. In case > > > > of alternate, top field and bottom field are in two different buffers. > > > > > > > > The question is, can we pass existing flags > > > > DRM_MODE_PRESENT_TOP_FIELD and DRM_MODE_PRESENT_TOP_FIELD > > to DRM_IOCTL_MODE_SETPLANE ioctl? > > > > > > The original idea with those flags was bob deinterlacing type of stuff. > > > > > > For fbs with non-interleaved fields I think we'd have to extend addfb > > > somewhat to allow passing a separate buffer for each field. The > > > problem with that is that we only have 4 buffers in addfb, so we'd run > > > out for three plane formats. So we'd have to increase the number of > > > buffers in addfb, or add some kind of implicit assumption on how the > > > fields are stored in the single bo (which I presume might not even be > > > possible on some crazy hardware). > > > > Yeah given that an fb is supposed to stick around potentially forever, I think > > we need to have both fields in one logical framebuffer object. But I have no > > idea how exactly we'd best go about for this, at least for true interlaced. > > Doubling up the drm_mode_fb_cmd2 structure (including fourcc and > > modifiers, or not?) is probably simplest. > > -Daniel > > [satish] As you know In alternate interlaced case each field buffer size > is 1920x540 (1920x1080i video resolution) and I have to submit fields > one after the other. I don't need to give them together for display. > Most of the modern interlaced displays are constructing a frame from a > field (by pixel interpolation). > > Imagine a capture and display use case: Where 1920x540 buffers are > captured, top field followed by bottom filed so on... There are chances > that some fields can be dropped from capture device. Then userspace will > have to communicate DRM with every field buffer if it is top or bottom. > Addfb2() will be called only once which cannot be called > throughout rendering lifecycle. So I have chosen DIRTY framebuffer > ioctl, where some area of fb is changing with every buffer. DRM doesn't work like this, you need to be able to keep showing the same framebuffer forever. That means you need a framebuffer with both fields. So only specifying the field on every flip (dirty fb doesn't do what you want to do here at all) isn't good enough. This is a huge difference in drm compared to v4l, where there's a queue of one-shot buffers. And you can just call addfb for every flip, the overhead is tiny for that. -Daniel -- 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
