| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Instead of attempting to fix these for GEM, just disable until GEM is
working.
|
|
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).
|
|
|
|
fd.o bz #15573
|
|
|
|
batchbuffer > aperture size.
So with compiz on Intel hw with fake bufmgr, opening 4 firefox windows at 1680x1050 and hitting alt-tab, could cause the batchbuffer to try and reference more than the 32MB of RAM allocated.
Fix 1:
Fix 1 is to pre-verify the list of buffers against the current batchbuffer and if it can't possibly fit in the aperture to flush the batchbuffer to the hardware
and try again. If the buffers still can't fit well then you are hosed as I'm not sure there is a nice way to tell anyone.
Fix 2:
Next problem was that even with a simple check for total < aperture, we ran
into fragmentation issues, this meant that half way down a set of buffers,
we would fail as no blocks were available. Fix this by nuking the memory
manager from orbit and letting it start again and relayout the blocks in a
manner that fits.
Fix 3:
Finally the initial problem we were seeing was a memcpy to a NULL backing store.
We seem to end up with a texture at some point that never gets mapped but ends up with data in it. compiz al-tab icons have this property. So I created a card dirty bit that memcpy's any buffer that is !static and is written to back to memory. This probably is wrong but it makes compiz work for now.
Caveats:
965 support is still fail.
|
|
|
|
|
|
965 after merging intel_context.c from i915 and i965. fix bug# 15152.
|
|
|
|
|
