| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The early Z stuff is supposed to be unsafe without some more work in the
enable/disable path (in particular, how do we want to get it disabled on
the way out to the X Server?), but at the moment is 6% in OA.
|
|
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.
|
|
We're on the way to telling the kernel about when we need fence regs on our
objects or not, and this will cut the number of places needing them.
|
|
|
|
Fixes failed viewport updates on glxgears (and other apps) resize since
e41780fedc2c1f22b43118da30a0103fa68b769f.
Bug #20473.
|
|
Bug #21691.
|
|
The docs actually explain this, but not in a terribly clear manner.
This nearly fixes the piglit cubemap testcase, except that something's
going wrong with the nearest filtering at 2x2 sizes in the testcase.
Looks good by visual inspection, though.
Bug #21692
|
|
|
|
In addition to being HW accelerated, it avoids the incorrect
(black) rendering of the mipmaps that SW was doing in fbo-generatemipmap.
Improves the performance of the mipmap generation and drawing in
fbo-generatemipmap by 30%.
|
|
Conflicts:
src/mesa/drivers/dri/i965/brw_curbe.c
src/mesa/drivers/dri/i965/brw_vs_emit.c
src/mesa/drivers/dri/i965/brw_wm_glsl.c
|
|
forgot to commit the changes to actually support 4x aniso filtering...
|
|
i915 actually supports up to 4 (according to header file - not tested),
i965 up to 16 (code already handled this but slightly broken), so don't use 2
for all chips, even though angular dependency is very high.
|
|
|
|
|
|
These LOD bias updates are covered by the texture state uploads in
*_texstate.c now.
|
|
Also enable them all regardless of screen bpp, as 32 bpp what I've been
testing against, and haven't been able to detect any screen bpp-specific
troubles with them.
|
|
This is nice when paired with INTEL_DEBUG=batch for debugging what's going
out to the hardware.
|
|
There's really no need for two negation fields. This came from the
GL_NV_fragment_program extension. The new, unified Negate bitfield applies
after the absolute value step.
|
|
|
|
This requires upgrading the interface so that the argument to
glXBindTexImageEXT isn't just dropped on the floor. Note that this only
fixes the accelerated path on Intel, as Mesa's texture format support is
missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8,
but in this case we're not doing the upload so we can't really work around it
that way).
Fixes bugs with compositors trying to use shaders that use alpha channels, on
windows without a valid alpha channel. Bug #19910 and likely others as well.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
The i965 hardware cannot do GL_CLAMP behavior on textures; an earlier
commit forced a software fallback if strict conformance was required
(i.e. the INTEL_STRICT_CONFORMANCE environment variable was set) and
2D textures were used, but it was somewhat flawed - it could trigger
the software fallback even if 2D textures weren't enabled, as long
as one texture unit was enabled.
This fixes that, and adds software fallback for GL_CLAMP behavior with
1D and 3D textures.
It also adds support for a particular setting of the INTEL_STRICT_CONFORMANCE
environment variable, which forces software fallbacks to be taken *all*
the time. This is helpful with debugging. The value is:
export INTEL_STRICT_CONFORMANCE=2
|
|
s/FRAG_RESULT_DEPR/FRAG_RESULT_DEPTH/
s/FRAG_RESULT_COLR/FRAG_RESULT/COLOR/
Remove FRAG_RESULT_COLH (NV half-precision) output since we never used it.
Next, we might merge the COLOR and DATA outputs (COLOR0, COLOR1, etc).
|
|
|
|
|
|
This saves an inadvertent round-trip to the X Server on DrawBuffers, which was
hurting some metaops.
|
|
|
|
Move the remaining extension string enables to intel_extensions.c.
Make sure that GL_NV_texture_env_combine4 is not enabled on i830.
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
|
|
|
|
A step toward consolidating i915/intel_state.c and i965/intel_state.c
|
|
|
|
|
|
intel_swapbuffers.c
|
|
We only allow combined depth+stencil renderbuffers so the complicated code
for splitting and combining separate depth and stencil buffers is no longer
needed.
|
|
|
|
Oops.
|
|
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Thanks to Eric for pointing it out.
|
|
Previously fog parameter and specular color are packed into the
same dword. Note specular color should be packed in BGRA for device,
so if fog parameter and specular color all are present, fog parameter
will dirty the alpha term of specular color. This fixes rendering
issue when playing 'Yo Frankie' on 915/945.
|
|
|
|
|
|
The i915 (and related graphics cores) only support TEXCOORDMODE_CLAMP and
TEXCOORDMODE_CUBE when using cube map texture coordinates, so fall back to
software rendering for other modes to avoid potential gpu hang issue. This
fixes scorched3d issue on 945GM(see bug 14539).
|
|
Intel docs state that only 830/845 have VBOs, 855/865 don't. So
lets just not use them on i8xx at all.
This restores the old pre-vbo code and uses it on all 8xx hw.
|
|
Instead, have i965 and i915 both call the generic function from their Viewport.
|
|
According to Keith the docs have these offsets the other way around
|
|
This avoids issues with dereferencing stale cliprects around intel_draw_buffer
time. Additionally, take advantage of cliprects staying constant for FBOs and
DRI2, and emit cliprects in the batchbuffer instead of having to flush batch
each time they change.
|
