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 <mar...@gmail.com> wrote: > 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