misc fixes for VC4

Jasper St. Pierre jstpierre at mecheye.net
Fri Jan 2 08:14:21 PST 2015


On Thu, Jan 1, 2015 at 10:31 PM, Keith Packard <keithp at keithp.com> wrote:

> Rob Clark <robdclark at gmail.com> writes:
>
> > What about simply not using GL_QUADS for the normal GL paths?  Is
> > using quads, vs tri's and a few extra vertices really going to be a
> > win on some other hw?  If not, avoiding quads would be a big help for
> > freedreno too..
>
> Without quads, you end up replicating a lot of vertices, which means a
> lot more data motion from CPU to GPU.
>

On a UMA system, that's effectively free. With a triangle fan and
glMultiDrawElements, you can get it down to four, same as a quad. Though
I'm not sure if mesa fully supports glMultiDrawElements.

I believe mesa supports primitive reset, so with a triangle fan and
primitive reset, you can get it down to five indices per quad.


> >> The big performance win, though, is fixing copyarea to give the GL
> >> information about the area that might be damaged by the operation,
> >> using the scissor.  Given that it's negative lines of code and not
> >> significant on i965, I think this is a pretty good idea.  I do wonder
> >> if we don't want to just always leave scissoring on, like I did to
> >> logic op.
> >
> > I'd implemented a similar thing in XA once upon a time... pretty much
> > must-have for tilers..
>
> Do you actually want a closer bounding box on the operation? Given that
> we're likely to have generated a very tight bounds when computing
> damage, I wonder if rejiggering the API to somehow remember that for the
> rendering code could be done?
>

Yeah, a tight scissor box for rendering would really help.


> --
> -keith
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150102/b84fa8d8/attachment.html>


More information about the xorg-devel mailing list