On Mon, 16 Sep 2019 16:29:05 -0400 Alyssa Rosenzweig <aly...@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? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev