On Thu, Oct 2, 2014 at 6:05 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Wed, Oct 1, 2014 at 12:06 PM, Marek Olšák <mar...@gmail.com> wrote: >> On Wed, Oct 1, 2014 at 11:02 AM, Chris Forbes <chr...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
