[Mesa-dev] [PATCH v3 01/17] panfrost: Extend the panfrost_batch_add_bo() API to pass access flags
Boris Brezillon
boris.brezillon at collabora.com
Sun Sep 22 13:34:28 UTC 2019
On Sun, 22 Sep 2019 09:26:45 -0400
Alyssa Rosenzweig <alyssa.rosenzweig at collabora.com> wrote:
> > +your collabora address
>
> Thank you
>
> > > > > I think this batch_add_bo should probably dropped altogether? This loop
> > > > > is dealing with constant buffers; the shaders themselves were added
> > > >
> > > > I'll double check. I couldn't find where BOs containing shader programs
> > > > were added last time I looked.
> > >
> > > Masking a real bug :o
> > >
> > > It should probably happen in panfrost_patch_shader_state....?
> >
> > Ok, I'll add it there, I wasn't sure this function was called for all
> > shaders, but looking at the code a second time it seems to be the case.
>
> I think so as well, yeah.
>
> > > As I stated before, I thought we should be adding the BO for
> > > wallpapering when we actually wallpaper, since that's a slow path. Not
> > > wallpapering is the default and ideally what most apps should do.
> >
> > Wallpapering happens too late (when we are flushing the batch) to have
> > an impact on the dep graph, but we can probably know that wallpapering
> > will be needed before that. My question remains though, are
> > vertex/tiler supposed to touch the texture BO they're reading from, or
> > should we only flag the BO for FRAGMENT use.
>
> Vertex/tiler should not touch the texture BO, unless you're texturing
> from the vertex shader (which we're not for wallpapering).
Okay, then adding the READ flag isn't really needed: a WRITE is more
constraining than a READ, and the FRAGMENT job already writes the FBO
BOs.
More information about the mesa-dev
mailing list