> > Although actually I am not at all sure what this batch_add_bo is doing
> > at all?
> >
> > 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....?
> > > void panfrost_batch_add_fbo_bos(struct panfrost_batch *batch)
> > > {
> > > + uint32_t flags = PAN_BO_ACCESS_SHARED | PAN_BO_ACCESS_WRITE |
> > > + PAN_BO_ACCESS_VERTEX_TILER |
> > > + PAN_BO_ACCESS_FRAGMENT;
> >
> > I think we can drop VERTEX_TILER here...? The buffers are written right
> > at the end of the FRAGMENT job, not touched before that.
>
> What about the read done when drawing the wallpaper? I guess it's also
> only read by the fragment job, but I wasn't sure.
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.
> > If nothing else is broken, this should allow a nice perf boost with
> > pipelining, so the vertex/tiler from frame n+1 can run in parallel with
> > the fragment of frame n (rather than blocking on frame n finishing with
> > the FBOs).
>
> Would require the kernel patches I posted earlier for that to
> happen ;-). Right now all jobs touching the same BO are serialized
> because of the implicit BO fences added by the kernel driver.
Sure~ Maybe this sort of bug was the reason you weren't seeing
improvement from those kernel patches?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
