On Thu, Jan 1, 2015 at 10:31 PM, Keith Packard <[email protected]> wrote:
> Rob Clark <[email protected]> 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 > > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > -- Jasper
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
