| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
The most egregious, and the one the bug report and failure in the cubemap
demo were about was introduced with intel_mipmap_pitch_align(), where a
"* 2" for the pitch calculation was lost. The base size < 32 case also
failed to align, which may have caused problems with render to texture.
Another bug would have broken 2x2/1x1 base mipmap levels by placing the
data where the hardware wouldn't look for it.
Other bugs remain with the layout of the small mipmap faces (hardware looks
for them in X,Y,Z,-X,-Y,-Z order along the bottom row, but we lay them out
X,-X,Y,-Y,Z,-Z).
|
|
|
|
Also clean up some other miscellaneous formatting nits while I'm at it.
|
|
|
|
DEPTH_STENCIL texture. (bug#14952).
|
|
|
|
|
