| Age | Commit message (Collapse) | Author |
|---|
|
Makefile.template
|
|
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
Most of these were to ensure that caches got synchronized between 2d (or meta)
rendering and later use of the target as a source, such as for texture
miptree setup. Those are replaced with intel_batchbuffer_emit_mi_flush(),
which just drops an MI_FLUSH. Most of the remainder were to ensure that
REFERENCES_CLIPRECTS batchbuffers got flushed before the lock was dropped.
Those are now replaced by automatically flushing those when dropping the lock.
|
|
|
|
Otherwise, we would assertion error when doing the final unreference of the
buffer with an outstanding map (catching the memory leak).
|
|
This may allow better concurrency (noop in openarena performance now), but is
also important for the previous commit -- otherwise, we may end up with
BufferData, draw_prims, BufferData and the draw_prims would use the new VBO
data instead of old. This could still occur with user-supplied VBOs and poor
use of MapBuffer without BufferData.
|
|
965 gains fixed TTM typing of the buffer object buffers and unused PBO
functions, and 915 gains buffer size == 0 fixes from 965.
|
|
Putting the bufmgr in the screen is not thread-safe since the emit_reloc
changes. It also led to a significant performance hit from pthread usage
for the attempted thread-safety (up to 12% of a cpu spent on refcounting
protection in single-threaded 965). The motivation had been to allow
multi-context bufmgr sharing in classic mode, but it wasn't worth the cost.
|
|
|
