| 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 were doubling up the offsets for the mipmap levels for CPU access.
Instead of reimplementing i945_miptree_layout_2d with 6 cube images
separated by qpitch, share that function and provide the level offsets
later.
Fixes piglit cubemap and fbo-cubemap.
|
|
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.
|
|
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
|
|
intel_miptree_pitch_align does this later on.
|
|
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.
|
|
Makefile.template
|
|
mipmap pitches must account for the device alignment requirements, which
used to be fairly simple; just align to a 4-byte boundary. However, to allow
textures to be drawn to under TTM, they now need to be aligned to a 64-byte
boundary. Placing all of the alignment constraints in a single function
allows this new constraint to be applied uniformly.
There was some pitch constraining code in intel_miptree_create, but that was
modifying the pitch long after the miptree had been layed out, so it only
served to wreck the mipmap and cause rendering errors.
|
|
|
|
In the process, fix some alignment issues:
- Scratch space allocation was aligned into units of 1KB, while the allocation
wanted units of bytes, so we never allocated enough space for scratch.
- GRF register count was programmed as ALIGN(val - 1, 16) / 16 instead of
ALIGN(val, 16) / 16 - 1, which overcounted for val != 16n+1.
|
|
which make small textures(4x4,2x2,1x1) work well.
|
|
This seems to work now. Also fix i945 set_level_info, need to match i915
behaviour for storing mip height, as it's assumed to be the mip width
(in texels) elsewhere and the division by 4 is done later (untested).
|
|
|
|
Based on a patch from Keith Whitwell, with some further fixes.
|
|
Use the i965 version as it has some fixes over the i915tex version.
|
