<div class="gmail_quote">On Wed, Aug 22, 2012 at 6:09 PM, Rob Clark <<a href="mailto:rob.clark@linaro.org" target="_blank">rob.clark@linaro.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> From: Rob Clark <<a href="mailto:rob@ti.com">rob@ti.com</a>> 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. </blockquote></div> 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. Scott