| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 7ce6517f3ac41bf770ab39aba4509d4f535ef663.
This reverts commit d60145d06d999c5c76000499e6fa9351e11d17fa.
I was wrong about which generations supported baselevel adjustment --
it's just gen4, nothing earlier. This meant that i915 would have
never used the mag filter when baselevel != 0. Not a severe bug, but
not an intentional regression. I think we can fix the performance
issue another way.
|
|
BaseLevel/MaxLevel are mostly used for two things: clamping texture
access for FBO rendering, and limiting the used mipmap levels when
incrementally loading textures. By restricting our mipmap trees to
just the current BaseLevel/MaxLevel, we caused reallocation thrashing
in the common case, for a theoretical win if someone really did want
just levels 2..4 or whatever of their texture object.
Bug #30366
|
|
We're always making a single-level, 0-baselevel miptree.
|
|
|
|
|
|
|
|
|
|
It turns out that computing a 56 byte key to look up a 20-byte object
out of a hash table was some sort of a bad idea. Whoops.
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] gl firefox-talos-gfx 37.799 38.203 0.39% 6/6
after:
[ 0] gl firefox-talos-gfx 34.761 34.784 0.17% 5/6
|
|
Noted on the mailing list for an app that puts each glyph for its text
into a separate texture.
|
|
Fixes #27213.
|
|
The pitch is not really an inherent part of the miptree, since it's
not part of any of the layout calculations, and it's dictated by the
libdrm-allocated region pitch now.
|
|
Bug #26966: 945 miptree pitch disagreement with libdrm.
|
|
This is the last pitch-dependent part of miptree setup.
|
|
fixes piglit fbo-copypix.
|
|
Shaves 60k off the driver from removing the broken spans code. This
means we now require 2.6.29, which seems fair given that it's a year
old and we've removed support for non-KMS already in the last release
of 2D.
|
|
The weirdness that led to the bumping of pitch for those 512/1024
pixels is that in taking a 2x2 subspan or bilinear filtering we'd end
up hitting the same channel in 2 different pages, leading to lower
performance. With tiling, that doesn't occur, so we don't need to
waste the memory.
|
|
|
|
Shaves 400 bytes or so from i915_dri.so.
|
|
This really isn't supported at this point. GEM's been in the kernel for
a year, and the fake bufmgr never really worked.
|
|
I fixed it properly as of 7216679c1998b49ff5b08e6b43f8d5779415bf54.
|
|
|
|
gen2/3/4 are easier to say than "8xx, 915-945/g33/pineview, 965/g45/misc",
and compares on generation are often easier than stringing together a bunch
of chipset checks.
|
|
Conflicts:
src/mesa/drivers/dri/radeon/radeon_fbo.c
src/mesa/drivers/dri/s3v/s3v_tex.c
src/mesa/drivers/dri/s3v/s3v_xmesa.c
src/mesa/drivers/dri/trident/trident_context.c
src/mesa/main/debug.c
src/mesa/main/mipmap.c
src/mesa/main/texformat.c
src/mesa/main/texgetimage.c
|
|
Conflicts:
src/mesa/shader/lex.yy.c
src/mesa/shader/program_lexer.l
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Conflicts:
src/mesa/drivers/dri/intel/intel_fbo.c
src/mesa/drivers/dri/intel/intel_mipmap_tree.c
src/mesa/drivers/dri/intel/intel_mipmap_tree.h
src/mesa/drivers/dri/intel/intel_tex_copy.c
src/mesa/drivers/dri/intel/intel_tex_image.c
|
|
By just using offsets, we confused the hardware's tiling calculations,
resulting in failures in miptree validation and blit clears.
Fixes piglit fbo-clearmipmap.
Bug #23552. (automatic mipmap generation)
|
|
|
|
|
|
|
|
This lets us get rid of intel_miptree_depth_offsets() and simplify all
of the calling code.
|
|
Use _mesa_is_format_compressed() instead.
|
|
Now gl_texture_image::TexFormat is a simple MESA_FORMAT_x enum.
ctx->Driver.ChooseTexture format also returns a MESA_FORMAT_x.
gl_texture_format will go away next.
|
|
Once we've freed a miptree, we won't see any more state cache requests
that would hit the things that pointed at it until we've let the miptree
get released back into the BO cache to be reused. By leaving those
surface state and binding table pointers that pointed at it around, we
would end up with up to (500 * texture size) in memory uselessly consumed
by the state cache.
Bug #20057
Bug #23530
|
|
|
|
1. new PCI ids
2. fix some 3D commands on new chipset
3. fix send instruction on new chipset
4. new VUE vertex header
5. ff_sync message (added by Zou Nan Hai <nanhai.zou@intel.com>)
6. the offset in JMPI is in unit of 64bits on new chipset
7. new cube map layout
|
|
Bug #22000.
|
|
Fixes assertion failure on norsetto shadow mapping demo.
|
|
Fixes shadowtex.c. And an assert is added to catch this sooner next time.
|
|
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 may hurt if miptree relayout occurs, since we can't blit Y tiled
objects. But it corrects depth tests on FBOs using textures.
|
|
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 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.
|
|
Fixes double-frees of some regions, once from the renderbuffer code and
once from the miptree itself.
Bug #19062
|
|
|
|
Makefile.template
|
|
Otherwise, we would use the pitch as width of the texture, and compiz would
render the pitch padding on the right hand side.
|
|
|
