[RFC weston] compositor: optimize/simplify shaders

Rob Clark rob.clark at linaro.org
Wed Aug 22 17:48:28 PDT 2012


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.

BR,
-R

>
> Scott
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>


More information about the wayland-devel mailing list