| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
Makefile
configs/default
progs/glsl/Makefile
src/gallium/auxiliary/util/u_simple_shaders.c
src/gallium/state_trackers/glx/xlib/xm_api.c
src/mesa/drivers/dri/i965/brw_draw_upload.c
src/mesa/drivers/dri/i965/brw_vs_emit.c
src/mesa/drivers/dri/intel/intel_context.h
src/mesa/drivers/dri/intel/intel_pixel.c
src/mesa/drivers/dri/intel/intel_pixel_read.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
|
|
This may or may not be required pre-965, but it doesn't seem unlikely, and
I'd rather be safe.
(cherry picked from commit b053474378633249be0e9f24010650ffb816229a)
|
|
This may or may not be required pre-965, but it doesn't seem unlikely, and
I'd rather be safe.
|
|
Otherwise, we would address beyond the end of our buffers. Fixes reliable
GPU segfault with texture_tiling=true and oglconform shadow.c.
Bug #22406.
|
|
|
|
While GEM covers this for execution it knows about, it doesn't know about
the batchbuffer we're preparing. Fixes piglit vbo-map-remap.c testcase.
|
|
|
|
This is somewhat nasty, but we need to do Y-tiled depth for FBO support.
May help with corruption and hangs since enabling texture tiling, and
since switching depth textures to Y tiled.
Fixes piglit depthtex.c on 965.
|
|
I was in the midst of fixing some blitting-with-Y-tiled issues when I
noticed this. Hopefully PBO usage will be a little more robust, as a
result.
|
|
|
|
This fixes a regression in region read performance that came in with the
texture tiling changes. Ideally we'd have an access flag coming in so we
could also use bo_map_gtt for writing, like we do for buffer objects.
Bug #22190
|
|
pbo might be system buffer based or attached to another region. Call
intel_bufferobj_buffer to make sure pbo has a buffer of its own.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
This may hurt if miptree relayout occurs, since we can't blit Y tiled
objects. But it corrects depth tests on FBOs using textures.
|
|
Thanks to Shuang He for catching this.
|
|
This is about a 30% performance win in OA with high settings on my GM45,
and experiments with 915GM indicate that it'll be around a 20% win there.
Currently, 915-class hardware is seriously hurt by the fact that we use
fence regs to control the tiling even for 3D instructions that could live
without them, so we spend a bunch of time waiting on previous rendering in
order to pull fences off. Thus, the texture_tiling driconf option defaults
off there for now.
|
|
Looking for memory leaks that were causing crashes in my environment
in a situation where valgrind would not work, I ended up improving
the i965 debug traces so I could better see where the memory was
being allocated and where it was going, in the regions and miptrees
code, and in the state caches. These traces were specific enough
that external scripts could determine what elements were not being
released, and where the memory leaks were.
I also ended up creating my own backtrace code in intel_regions.c,
to determine exactly where regions were being allocated and for what,
since valgrind wasn't working. Because it was useful, I left it in,
but disabled and compiled out. It can be activated by changing a flag
at the top of the file.
|
|
This doesn't seem to really effect anything but seeing width=0 in drawing
regions was confusing.
|
|
This lets us avoid allocing new buffers for renderbuffers, finalized miptrees,
and PBO-uploaded textures when there's an unreferenced but still active one
cached, while also avoiding CPU waits for batchbuffers and CPU-uploaded
textures. The size of BOs allocated for a desktop running current GL
cairogears on i915 is cut in half with this.
Note that this means we require libdrm 2.4.5.
|
|
|
|
This is part of the deprecated pageflipping infrastructure.
|
|
Previously, we were trying to pass a name to the GEM GET_TILING_IOCTL,
which needs a handle, and failing. None of our buffers were tiled yet, but
they will be at some point with DRI2 and UXA.
|
|
|
|
Otherwise, we would use the pitch as width of the texture, and compiz would
render the pitch padding on the right hand side.
|
|
|
|
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
|
|
|
|
This was broken in the merge of 965 blit support. It tried to lock only
when things were already locked.
|
|
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.
|
|
|
|
Fencing was used in two places: ensuring that we didn't get too many frames
ahead of ourselves, and glFinish. glFinish will be satisfied by waiting on
buffers like we would do for CPU access on them. The "don't get too far ahead"
is now the responsibility of the execution manager (kernel).
|
|
|
|
|
|
In addition to potentially binding when it was about to be mapped anyway,
failure to use CACHED_MAPPED means eating a full wbinvd on validate. Thanks to
airlied for catching this.
|
|
this fix bad texture issue in some games(UT and quake).
|
|
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.
|
|
965 gains fixed TTM typing of the buffer object buffers and unused PBO
functions, and 915 gains buffer size == 0 fixes from 965.
|
|
This adds (so far) unused PBO functions, and holding the lock while writing
to regions (which may be shared static screen regions).
|
|
The idling it was trying to ensure was covered by the
intel_miptree_image_map()->intel_region_map() that immediately followed it.
|
|
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 requires that regions grow a marker of whether they are tiled or not,
because fence (surface) registers are ignored by the 965 2D engine.
|
|
|
|
|
