[Mesa-dev] [PATCH 1/7] mesa: Add usage history bitfield to buffer objects
chrisf at ijw.co.nz
Thu Oct 2 02:57:22 PDT 2014
That fixes the bug and is nice and minimal, but it doesn't meet my
_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.
More information about the mesa-dev