| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Mesa requires that we be able to share objects between contexts, which means
that the objects need to be created by the same bufmgr, and the bufmgr
internally requires pthread protection for thread safety.
Rely on the bufmgr having appropriate locking.
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
|
|
The boolean that the server gives us for whether the region is tiled was
getting used as the enum for what tiling mode. Instead, guess the correct
tiling in screen setup.
Also, fix the Y-tiling pitch setup. The pitch to the next tile in Y is
32 scanlines, not 8.
|
|
Accessing tiled surfaces without using the fence registers requires that
software deal with the address swizzling itself.
|
|
|
|
The screen wide info such as pitch and cpp are obsoleted by the FBO
changes, so clean up the last few references to those, except for
setting up the legacy screen regions.
|
|
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.
|
|
This could lead to incorrect rendering or even lockups.
|
|
This requires that regions grow a marker of whether they are tiled or not,
because fence (surface) registers are ignored by the 965 2D engine.
|
|
This was replaced in previous releases of xserver/dri/libGL by reporting the
damage to the frontbuffer so that the server and driver could handle it
appropriately.
|
|
|
