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?
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