[Mesa-dev] [PATCH 14/17] i965: Grow the batch/state buffers if we need space and can't flush.

[Kenneth Graunke]

On Wednesday, September 6, 2017 8:44:03 AM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2017-09-06 16:20:00)
> > On Wednesday, September 6, 2017 3:08:44 AM PDT Chris Wilson wrote:
> > > Quoting Kenneth Graunke (2017-09-06 01:09:47)
[snip]
> > > > +/* Don't exceed this - batchbuffers need to fit in the ring! */
> > > 
> > > I don't understand this comment. I probably just have the wrong pov, you
> > > say ring and I then think of the legacy/lrc ringbuffer in the kernel.
> > 
> > My understanding was that the legacy Gen4-7.5 ringbuffer mode allocated a
> > ringbuffer that was...128kB large?  So if you exceeded that size, the
> > batch would not fit in the ring at all, and execbuf would fail.
> 
> We don't copy the batch into the ring, we just stick a
> MI_BATCH_BUFFER_START in there (with a flush before/after and a
> breadcrumb, along with any context switch, change of mm, etc).

Oh, right...so that doesn't make sense.

> 64k is indeed a magic limit for the state batch though, but as there's

What causes this limit?

> no limit on the batch buffer size (after converting it to a pure command
> stream, just the prospect of a timeout). Well... There is an implicit
> assumption that you don't exceed 256KiB for a batch (as a limit for a gen2
> workaround and a different gen7 workaround).
> 
> Elsewhere, I have used 256KiB batches (and then shrunk to fit) simply
> because of UINT16_MAX dwords. (Which is kind of why the kernel assumes
> that the upper reasonable maximum size is 256KiB for its w/a.)

Should I change this to 256kB then?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170908/f6acadbb/attachment.sig>