[Mesa-dev] [PATCH 1/7] mesa: Add usage history bitfield to buffer objects

[Chris Forbes]

That fixes the bug and is nice and minimal, but it doesn't meet my
overhead-reduction goal.

_NEW_TEXTURE triggers piles of work, mostly irrelevant if we've only
changed buffer textures.

On Thu, Oct 2, 2014 at 10:28 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Thu, Oct 2, 2014 at 6:05 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Wed, Oct 1, 2014 at 12:06 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> On Wed, Oct 1, 2014 at 11:02 AM, Chris Forbes <chrisf at ijw.co.nz> wrote:
>>>> In the drivers, we occasionally want to reallocate the backing
>>>> store for a buffer object; often to avoid waiting for the GPU
>>>> to be finished with the previous contents.
>>>>
>>>> At the point that happens, we don't have a good way of determining
>>>> where else the buffer object may be bound, and so no good way of
>>>> determining which dirty flags need to be raised -- it's fairly
>>>> expensive to go looking at all the possible binding points.
>>>
>>> I don't think so. We do look at all binding points in radeon drivers.
>>> See for example r600_invalidate_buffer. It also only flags the binding
>>> points where the buffer being invalidated is bound and only those
>>> bindings points are updated.
>>>
>>> Also I don't see a point in adding things to mtypes.h that are only
>>> used by one driver.
>>
>> Without commenting on the approach, Chris's new test does fail on
>> nvc0. Perhaps check radeon as well? Could be some sort of driver fail
>> there, of course, I didn't spend too much time investigating. I
>> figured we'd need the same fix in mesa/st.
>
> It fails because texbufferrange doesn't flag anything, so st/mesa
> doesn't know. Replacing FLUSH_VERTICES(ctx, 0) with:
>
> FLUSH_VERTICES(ctx, _NEW_TEXTURE);
>
> fixes it for radeon.
>
> Marek