On Mon, Apr 22, 2013 at 6:28 PM, Eric Anholt <e...@anholt.net> wrote: > 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.
Very good points. You're right. I'll discard this patch. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
