[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