[RFC weston] compositor: optimize/simplify shaders

[Pekka Paalanen]

On Wed, 22 Aug 2012 19:48:28 -0500
Rob Clark <rob.clark at linaro.org> wrote:

> On Wed, Aug 22, 2012 at 7:38 PM, Scott Moreau <oreaus at gmail.com> wrote:
> >
> >
> > On Wed, Aug 22, 2012 at 6:09 PM, Rob Clark <rob.clark at linaro.org> wrote:
> >>
> >> From: Rob Clark <rob at ti.com>
> >>
> >> Re-work how the shaders and emitted vertices work.  Rather than always
> >> rendering clip-rect sized quads and doing transformation in tex coords
> >> (and requiring the corresponding clipping in frag shader), instead
> >> emit transformed vertices, clipped wrt. dirty region, and use simpler
> >> frag shaders.  Also, split the rendering, so blended surfaces with an
> >> opaque region have the opaque region drawn with blend disabled.  The
> >> result is considerably fewer pixels drawn with blend enabled, and much
> >> fewer cycles in the frag shader.
> >>
> >> This requires having some more complex logic to figure out the vertices
> >> of the shape which forms the intersection of the clip rect and the
> >> transformed surface.  Which has perhaps got a few bugs or missing cases,
> >> still (visual glitches in some cases) but at this point more or less is
> >> starting to work.  I think it is at least far enough along to get some
> >> initial review.
> >>
> >> The result, on small SoC GPU (omap4/pandaboard) on 1920x1080 display,
> >> for simple stuff like moving windows around, I get 60fps (before 30fps
> >> or less), and pushing YUV buffers for hw decoded 1080p video goes from
> >> ~6fps to 30fps, with no drop in framerate for transformed/rotated video
> >> surface.
> >
> >
> >
> > Hi Rob,
> >
> > It appears you have gained considerable performance with these
> > optimizations. I'm wondering though, does this make the assumption surfaces
> > are always rectangular with no advanced geometry? For instance, would you
> > still be able to do advanced effects such as wobbly surfaces or an explode
> > animation? Perhaps the draw routines could be made so that custom data could
> > be structured. Just a thought.
> >
> 
> I did think briefly about wobbly windows.  I *think* we could either
> revert to a less optimal path then, or maybe just expand the bounding
> region of the surface.  I'm not entirely sure yet the best approach,
> but I think for wobbly windows it would likely be only be a single
> surface, and it would be the front-most surface, so it seems like we
> should be able to play some clever tricks based on those assumptions.

Hi,

let's not consider wobblies or any similar advanced cases for now. If
we wanted to, the code could be written to clip triangle meshes, for
instance.

However, as wobblies are slightly off-topic for a reference compositor,
and advanced effects have no implications to clients nor the protocol,
we should ignore them.

Performance on the other hand is important.

Good work Rob, I'll look into your patch.


Thanks,
pq