On Thursday, May 3, 2018 11:49:51 PM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2018-05-04 02:12:38)
> > We'd like to start using soft-pin to assign BO addresses up front, and
> > never move them again.  Our previous plan for dealing with 48-bit VF
> > cache bugs was to relocate vertex buffers to the low 4GB, so we'd never
> > have addresses that alias in the low 32 bits.  But that requires moving
> > buffers dynamically.
> > 
> > This patch tracks the last seen BO address for each vertex/index buffer,
> > and emits a VF cache invalidate if the high bits change.  (Ideally, we
> > won't hit this case very often.)  This should work for the soft-pin
> > case, but unfortunately won't work in the relocation case, as we don't
> > actually know the addresses.  So, we have to use both methods.
> 
> It can only be moved between batches; and between batches there is a
> PIPE_CONTROL_VF_CACHE_INVALIDATE. Is there more to this w/a, or is it
> truly unnecessary? See gen8_emit_flush_render() and double check that is
> sufficient.
> -Chris

In the old approach, the moment a batch used a buffer as a vertex
buffer, we would pin it to 4GB.  If it had been at some other address,
it would be relocated there for the entire batch.  This ensures that
all vertex buffers have a 32-bit address.

Now that we're fixing an address for BO's up front, those buffers might
have high address bits.  We don't relocate and can't move them at all.
The VF only considers the low 32 bits of the address, plus the VB index.

So, if the VF contained data for VB[5] at 0x1000 and then we bound a new
VB[5] at 0x100001000, the cache would give us bogus data from the first
buffer when it ought to miss and read the second.  To work around this,
this patch introduces code to do a VF cache invalidate if the top bits
for a particular VB[i] ever change.

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to