Age | Commit message (Collapse) | Author |
|
|
|
|
|
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.
|
|
|
|
Fix http://bugs.freedesktop.org/show_bug.cgi?id=16287.
|
|
The fallback was introduced to fix bug #16697, but made the test it was
fixing run excessively long.
|
|
Without this, we would reject programs which sampled multiple times from
registers defined in the same phase (block of instructions with the same
texture indirection count), as each sample would count as a new phase
beginning. Instead, keep track of which phases registers were written in,
and only bump phase when we're reading from one generated in this phase.
On the other hand, we failed to count oC or oD texture samples as being new
phases.
Bug #17865.
|
|
The ARB extension is a superset of the older SGIX extension. Any
hardware that can support the SGIX version can also support the ARB
version. In Mesa, any driver that supports one also supports the
other. This unification just simplifies some bits of code.
|
|
|
|
|
|
Makefile.template
|
|
|
|
|
|
|
|
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
To do this, I had to clean up some of 965 state upload stuff. We may end
up over-emitting state in the aperture overflow case, but that should be rare,
and I'd rather have the simplification of state management.
|
|
Conflicts:
src/mesa/drivers/dri/common/dri_bufmgr.c
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
Enable support for ARB_texture_env_crossbar in the master extension
list instead of in every single device-specific list.
|
|
|
|
enabled for 1D texture. fix #12176
|
|
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.
|
|
|
|
|
|
|
|
This lets GEM use pwrite, for an additional 4% or so speedup.
|
|
|
|
The fencing code is not required, and waiting on the fences defeated one of
the purposes of the extension, which is to allow asynchronous readpixels.
|
|
|
|
The no_rast fallback was getting partially overwritten by later TNL init,
resulting in a segfault when things were in a mixed-up state.
|
|
This is an API breakage only.
|
|
|
|
|
|
Otherwise, since the MI_FLUSH at the end of every batch had been removed,
non-automatic-flushing chips (965) wouldn't get flushed and apps with static
rendering would get partial screen contents until the server's blockhandler
flush kicked in.
|
|
The GEM flags are much more descriptive for what we need. Since this makes
bufmgr_fake rather device-specific, move it to the intel common directory.
We've wanted to do device-specific stuff to it before.
|
|
|