Marek Olšák <mar...@gmail.com> writes: > A driver doesn't have to set _NEW_BUFFER_OBJECT if it doesn't reallocate > the buffer from core Mesa's point of view, which avoids unnecessary state > validation. > > Gallium drivers can be asked to reallocate a buffer privately by setting > PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE. > > st/mesa doesn't set _NEW_BUFFER_OBJECT if transfer_inline_write is used.
_NEW_BUFFER_OBJECT is used in Mesa core only for MaxElement updates. So Mesa core could flag its state update only when size changes and have its state tracking correct, and then the question is what drivers need to track internally when they need to, say, shove a new BO data pointer down to the hardware. Elsewhere, your plan seems to be for drivers to define their own flags, while in this case you have the driver start adding core flags to NewState. We have a few cases of that already (radeon FBOs, and a piece in st_cb_fbo.c that looks dubious), but I think I'd rather see progress towards making that go away in favor of NewDriverState like you do in the rest of the series. > diff --git a/src/mesa/drivers/dri/nouveau/nouveau_bufferobj.c > b/src/mesa/drivers/dri/nouveau/nouveau_bufferobj.c > index 717c0b8..2508933 100644 > --- a/src/mesa/drivers/dri/nouveau/nouveau_bufferobj.c > +++ b/src/mesa/drivers/dri/nouveau/nouveau_bufferobj.c > @@ -79,7 +79,9 @@ nouveau_bufferobj_data(struct gl_context *ctx, GLenum > target, GLsizeiptrARB size > struct nouveau_bufferobj *nbo = to_nouveau_bufferobj(obj); > int ret; > > - obj->Size = size; > + ctx->NewState |= _NEW_BUFFER_OBJECT; > + > + obj->Size = size; > obj->Usage = usage; > > /* Free previous storage */ nouveau is tab indentation (quite consistently, too). I should dump in the .dir-locals.el needed, since I threw some together for my recent swrast work.
pgpwuenVrHrN9.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
