[Mesa-dev] [PATCH 03/14] mesa: move _NEW_BUFFER_OBJECT flagging from BufferData to drivers

[Marek Olšák]

On Mon, Apr 22, 2013 at 6:28 PM, Eric Anholt <eric at anholt.net> wrote:
> Marek Olšák <maraeo at 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