Technically, this isn't actually a problem because blorp manually whacks BRW_NEW_URB_SIZE. That said, triggering on NEW_BLORP is a better plan anyway. With this patch, we can probably remove the line from blorp where it sets NEW_URB_SIZE.
On Fri, Jun 16, 2017 at 2:01 PM, Ian Romanick <i...@freedesktop.org> wrote: > From: Jason Ekstrand <jason.ekstr...@intel.com> > > It's a bit rare, but blorp can trigger a urb reconfiguration. When that > happens, we need to re-upload the URB config. Fortunately, this isn't as > bad as it looks because gen7_upload_urb will not re-emit the packet if it > would end up being a no-op so this doesn't mean that running blorp always > triggers a URB reconfig. > > v2 (idr): Sort BRW_NEW_ tokens to match brw_recalculate_urb_fence and > gen6_urb. > --- > src/mesa/drivers/dri/i965/gen7_urb.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c > b/src/mesa/drivers/dri/i965/gen7_urb.c > index 525c9c4..c4b479c 100644 > --- a/src/mesa/drivers/dri/i965/gen7_urb.c > +++ b/src/mesa/drivers/dri/i965/gen7_urb.c > @@ -236,7 +236,8 @@ gen7_upload_urb(struct brw_context *brw, unsigned > vs_size, > const struct brw_tracked_state gen7_urb = { > .dirty = { > .mesa = 0, > - .brw = BRW_NEW_CONTEXT | > + .brw = BRW_NEW_BLORP | > + BRW_NEW_CONTEXT | > BRW_NEW_URB_SIZE | > BRW_NEW_GS_PROG_DATA | > BRW_NEW_TCS_PROG_DATA | > -- > 2.9.4 > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev