[RFC 0/9] nuclear pageflip

[Rob Clark]

On Wed, Sep 12, 2012 at 1:58 PM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
>> On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä
>> <ville.syrjala at linux.intel.com> wrote:
>> > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
>> >> But I think we could still do this w/ one ioctl per crtc for atomic-pageflip.
>> >
>> > We could, if we want to sacrifice the synced multi display case. I just
>> > think it might be a real use case at some point. IVI feels like the most
>> > likely short term cadidate to me, but perhaps someone would finally
>> > introduce some new style phone/tablet thingy. I have seen
>> > concepts/prototypes of such multi display gadgets in the past, but the
>> > industry apparently got a bit stuck on the rectangular slab with
>> > touchscreen on one side design.
>>
>> I could be wrong, but I think IVI the screens would normally be too
>> far apart to matter?
>
> I was thinking of something like a display on the dash that normally
> sits low with only a small sliver visible, and extends upwards when
> you fire up a movie player for example. Internally it could be made
> up of two displays for power savings purposes.
>
>> Anyways, it is really only a problem if you can't do two ioctl()s
>> within one vblank period. If it actually turns out to be a real
>> problem,
>
> Well exactly that's the problem this whole atomic pageflip stuff is
> trying to tackle, no? ;)
>
>> we could always add later an ioctl that takes an array of
>> 'struct drm_mode_crtc_atomic_page_flip's.  I'm not sure if this is
>> really useful or not.. but maybe I'm thinking too much about how
>> weston does it's rendering of different output's independently.
>
> I'm just now thinking of surfaceflinger's way of doing things, with
> its prepare and commit phases. If you need to issue two ioctls to handle
> cloned displays, then you can end up in a somewhat funky situation.
>
> Let's say you have a video overlay in use (one each display naturally),
> and you increase the downscaling factor enough so that you now have
> enough memory bandwith to support only one overlay. With independent
> check ioctls for each display, you never have the full device state
> available in the kernel, so each check succeeds during the prepare
> phase. So you decide that you can keep using the video overlays.
>
> You then proceed to commit the state, but after the first display has
> been commited you get an error when trying to commit the second one.
> What can you do now? The only option is to keep displaying the old
> frame on the other displays for some time longer, and then on the
> next frame you can switch to GPU composition. But on the next frame you
> perhaps no longer need to use GPU composition, but since you can't
> verify that in the prepare phase, you have no other option but to use
> GPU composition.
>
> So when you run into a configuration that can be supported only
> partially, you get animation stalls on some displays due to skipped
> frames, and you always have to fall back to GPU composition for the
> next frame.
>
> If on the other hand you would check the whole state in one ioctl,
> you'd get the error in the first prepare phase, and could fall back
> to GPU composition immediately.
>
> Am I too much of a perfectionst in considering such things? I don't
> think so, but perhaps other people disagree.

Ok, if you have a case where the state of the two crtc's are not
actually independent, then I think you have a valid point.

I'm not quite sure what userspace would do about it, though.. for the
general case where vsync isn't locked, and you can't even necessarily
assume vsync period is the same, then I don't really think you want to
couple rendering to the displays.  OTOH, the 'test' step can come
independent of vblank, so maybe you'd want to do the 'test' step
together, and then the flip parts independently.  Hmm...

>> I wonder.. if you have some special hw setup where you can keep the
>> multiple display's in sync-lock, maybe a special virtual crtc would
>> work.  That way userspace it appears as a single display.  I'm not
>> really sure how crazy that would be to implement.
>
> Sure, add more abstraction layers and you can solve any problem :)

well, not really.. but my point was this sort of setup would be a
somewhat custom hardware setup, so maybe some hack in that case isn't
such a bad idea.  I dunno..

>> But I think in the
>> common case, where the displays are not vsync locked, treating the
>> page flips of different crtc's independently, and rendering the
>> contents for different outputs independently (like weston) makes the
>> most sense.
>
> My API design doesn't preclude that at all. In light of my android tale
> above how would weston decide whether it can use overlays in such a
> case?

>From userspace API, I guess something like:

struct drm_mode_crtc_atomic_page_flip {
	uint32_t flags;
	uint32_t count_crtcs;
	uint64_t crtc_ids_ptr;  /* array of uint32_t */
	uint64_t count_props_ptr; /* array of uint32_t, # of prop's per crtc */
	uint64_t props_ptr;  /* ptr to array of drm_mode_obj_set_property */
	uint64_t user_data;
};

Or maybe just have something similar to my current ioctl, and then a
drm_mode_crtc_multi_atomic_page_flip which takes an array of
drm_mode_crtc_atomic_page_flip.

Or possibly just use atomic_mode_set ioctl for the test step, and
atomic_page_flip per crtc for the page-flip step.  The test step can
be done independently of vblank, so it doesn't really matter if there
is a vblank pending or not.

BR,
-R


> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel