[Mesa-dev] [PATCH v2 00/37] panfrost: Support batch pipelining

[Alyssa Rosenzweig]

"Can't use pipe_framebuffer_state as a hash key" Is this still relevant?
I thought we did this.

You're right that the 32-batch bitset is something we can integrate in a
v2.

I guess that's it, never mind. Good stuff regardless :)

On Tue, Sep 17, 2019 at 12:08:34AM +0200, Boris Brezillon wrote:
> On Mon, 16 Sep 2019 16:29:05 -0400
> Alyssa Rosenzweig <alyssa at rosenzweig.io> wrote:
> 
> > > As a drive-by comment, in case you didn't know, the "standard"
> > > solution for avoiding flushing when BO's are written by the CPU (e.g.
> > > uniform buffer updates) as documented in ARM's performance guide is to
> > > add a copy-on-write mechanism, so that you have "shadow" BO's when the
> > > original BO is modified by the user. I believe this is implemented in
> > > freedreno, at least there was a talk about it at XDC a few years ago.  
> > 
> > Yes, this is implemented in freedreno. BO shadowing will be the next
> > step once this pipelining code settles down. For now, this series is
> > about eliminating the strict flushes between each and every frame of
> > each and every FBO that we currently occur now.
> > 
> > Boris, references on the freedreno model (which is the mesa gold
> > standard):
> > 
> > https://www.x.org/wiki/Events/XDC2016/Program/clark_ooo_rendering.pdf
> > https://bloggingthemonkey.blogspot.com/2016/07/dirty-tricks-for-moar-fps.html
> > 
> > The former presentation is definitely worth a read; evidently we've
> > already painted ourselves into some corners :p
> 
> I had a quick look at the presentation, and it looks pretty similar to
> what is being implemented in this series. The only difference I could
> spot is the limitation to 32 batches to avoid usage of sets in the BO
> access tracking logic, and that's still something I can change (I'd
> prefer to do that in a follow-up patch though).
> 
> What specific aspects do you think we got wrong?