Re: [PATCH weston v2 0/68] Atomic modesetting, planes, extended drm_fb

2016-12-09 Thread Daniel Stone
Hi,

On 9 December 2016 at 19:58, Daniel Stone  wrote:
> This is v2 of the atomic patchset, which incorporates quite a few
> fixups on the original code, and extends it far enough to flip
> sprites_are_broken off for atomic. \o/

And it lives here:
git://git.collabora.com/git/user/daniels/weston#wip/phab/T7595-atomic-modeset

> First we try to construct a view made entirely out of planes and
> nothing else; if this succeeds, we just use that and we don't need to
> render anything. Failing that, we try to incrementally build a state,
> trying one view at a time on one plane at a time, and seeing if that
> changes anything. Doing this is what lets us flip sprites_are_broken,
> because we can not only generate an optimal configuration, but make
> sure it'll actually work when we do it.

There are a couple of things I'm not entirely happy with here in
hindsight, that a nice long walk has helped clarify.

The duplicate_renderer dance in drm_output_propose_state /
drm_output_prepare_scanout_view is messy, and in fact leaks the old
state when we successfully promote a view to scanout. I did play
around with special-casing the drm_plane_state_*() API to deal with
this, but didn't like the non-obviousness it introduced. I think a
cleaner solution might just be to duplicate the entire output_state;
I'll have another play around with both (and a clearer head) next
week.

The 'test plane states' commit is obscured by the fact overlay
assignment moves from picking one plane early and sticking to that, to
testing all the planes in a loop. I was trying to avoid exploding the
series into too many patches, but may have got the balance wrong
there. I'll probably change that in the next iteration.

I think we also need to delay start_repaint_loop() if we have a DPMS
off that hasn't completed; in testing just now I was able to hit a
rare breakage (hooray for asserts!) which I suspect was exactly this.

Short of this, any general commments welcome, as well as review of the
earlier patches in the series (thanks Armin!), so we can start landing
the less dangerous/controversial pieces and trim the series down a
bit. Testing on exotic platforms is always good too: I have Intel,
Rockchip (with the Mali driver), and Raspberry Pi (less interesting as
it can't put client surfaces in planes) here, and hopefully will have
Freedreno running next week. Maybe Tegra if Alexandre posts a tree
with that working too.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel


[PATCH weston v2 0/68] Atomic modesetting, planes, extended drm_fb

2016-12-09 Thread Daniel Stone
Hi all,
This is v2 of the atomic patchset, which incorporates quite a few
fixups on the original code, and extends it far enough to flip
sprites_are_broken off for atomic. \o/

Compared to earlier versions, drm_output_state is introduced much
earlier, and everything hangs off this. This made a lot of things much
more clean than they used to be. Most of the patches before this are
relatively untouched, but for bugfixes.

The pixel-format helpers patch is new, after I got frustrated at
having to write yet another table of formats with validation. I'm
fully intending to convert gl-renderer over to using this for its SHM
upload path, but on the other hand I didn't want to tie that together
with this series; it's big enough as it is. (Similarly, for
multi-output you'll need the 'Assign new views to the primary plane'
patch I sent out earlier, separately.)

On top of the code from v1, which is primarily concerned with how we
apply state, v2 attacks how we _generate_ the state in the first
place. The major difference is the whittling down of the
prepare_*_view() functions into common helpers, and then cleaving
assign_planes() in two. Doing the latter allows us to actually
reasonably do atomic TEST_ONLY.

First we try to construct a view made entirely out of planes and
nothing else; if this succeeds, we just use that and we don't need to
render anything. Failing that, we try to incrementally build a state,
trying one view at a time on one plane at a time, and seeing if that
changes anything. Doing this is what lets us flip sprites_are_broken,
because we can not only generate an optimal configuration, but make
sure it'll actually work when we do it.

Included in with this is a set of patches which let us import more
exotic buffers: primarily multi-planar, and with buffers. The earlier
work means that this is now generalised, and we can use them for
scanout, overlay, or anything really.

After this, a set of optimisation patches to ignore views which aren't
on other outputs and occluded views. This prevents us from triggering
spurious repaints on multi-head systems.

At the end of this, on my multihead setup, I was able to set up one
fullscreen (but scaled, due to HiDPI) and one non-fullscreen view
above it. With nothing else on screen, these were promoted to planes
(scanout and overlay, respectively), and no rendering was done. When
something was moved on top of them, they moved back to GPU composition
where necessary.

Any review or testing would be appreciated; I have no idea when 1.13
is supposed to be (in 11 days ...?), so I assume it won't land for
then, but I'd like to get this in as early as possible for the 1.14
cycle, so we can iron out as many of the bugs as possible.

Many thanks to Fabien DESSENNE for testing and fixes, Tomohito Esaki
for the dmabuf-without-GBM patch, Derek Foreman and others for things
like cursor clipping (already fixed, but the reports were nice). And
of course, I somehow forgot to mention in my original mail - to Pekka
Paalanen, Louis-Francis Ratté-Boulianne and Derek Foreman, who worked
on much earlier iterations of atomic support.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel