| 9da50667f490ba2c6240f4c91c9707e3f181adae |
|
10-Aug-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
intel: Move finish_batch() call before MI_BATCH_BUFFER_END and padding.
On Gen4+, brw_finish_batch() calls brw_emit_query_end(), which emits
some extra PIPE_CONTROLs to capture the current occlusion query data.
Unfortunately, it was being called *after* _intel_batchbuffer_flush
added the MI_BATCH_BUFFER_END, meaning those PIPE_CONTROLs didn't get
inside the batch.
Not only does this likely cause bogus occlusion query values, it can
also cause crashes: with the recent change to use 64-bit depth count
writes on Gen6+, we started emitting an odd-length PIPE_CONTROL, which
happened after the MI_NOOP padding. This resulted in an odd-length
batch buffer, which resulted in execbuf2 returning -EINVAL and the
application dying with an intel_do_flush_locked failure.
On older generations, finish_batch() doesn't emit any state, so this
change shouldn't have any effect.
Huge thanks to Chris Wilson for helping me figure this out.
NOTE: This is a candidate for stable release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53311
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 61d0b9f52c6be4a4a64c30ea3a2a93ef8260c67b |
|
26-Jul-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
intel: Make the length for PIPE_CONTROL explicit.
PIPE_CONTROL has variable length, depending upon generation and whether
we want to do 32-bit or 64-bit data writes. Make it explicit, rather
than hiding a length of 4 in the #define for _3DSTATE_PIPE_CONTROL.
Generated by s/3DSTATE_PIPE_CONTROL/3DSTATE_PIPE_CONTROL | (4 - 2)/g.
This is equivalent since the #define used to have | 2 in it. A grep
through the sources shows that all instances have been converted, so
it's safe to remove the | 2 from the #define.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 860d5bdf984730f69cd19b4f7145f3c84b57d33d |
|
12-Jun-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Add hardware context support.
With fixes and updates from Ben Widawsky and comments from Paul Berry.
v2: Use drm_intel_gem_context_destroy to destroy hardware context;
remove useless initialization of hw_ctx, both suggested by Eric.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| ea8e854b2cefc3f3590b6c19e6108a471be951ba |
|
07-May-2012 |
Paul Berry <stereotype441@gmail.com> |
i965: Completely annotate the batch bo when aub dumping.
Previously, when the environment variable INTEL_DEBUG=aub was set,
mesa would simply instruct DRM to start dumping data to an .aub file,
but we would not provide DRM with any information about the format of
the data in various buffers. As a result, a lot of the data in the
generate .aub file would be unannotated, making further data analysis
difficult.
This patch causes the entire contents of each batch buffer to be
annotated using the data in brw->state_batch_list (which was
previously used only to annotate the output of INTEL_DEBUG=bat). This
includes data that was allocated by brw_state_batch, such as binding
tables, surface and sampler states, depth/stencil state, and so on.
The new annotation mechanism requires DRM version 2.4.34.
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 709f50928e1d4df755ffb90ec9f33ba6c9605a32 |
|
19-Jan-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Emit Ivybridge VS workaround flushes.
I recently discovered this text in the BSpec. It seems wise to comply,
though I haven't observed it to fix anything yet.
Fixes a regression in glean/fbo since 28cfa1fa213fe.
NOTE: This is a candidate for stable release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45221
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 65b096aeddd9b45ca038f44cc9adfff86c8c48b2 |
|
01-Feb-2012 |
Ian Romanick <ian.d.romanick@intel.com> |
intel: Remove num_mapped_regions assertion from _intel_batchbuffer_flush
There are cases where a buffer can be mapped while another buffer is
flushed. This can happen in the CopyPixels meta-op path for piglit's
fbo-mipmap-copypix. After some discussion with Eric, it seems this
assertion is no longer necessary, and it has always been too strict.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43328
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 61b9ccd9e298ca1d3db55aee0cb2ff78662d6fa6 |
|
20-Dec-2011 |
Eric Anholt <eric@anholt.net> |
intel: Use libdrm's decode functionality instead of the gpu-tools copy.
While typing out the new decode, I added a fallback mode for dumping
when we fail to re-map the BO after execution. This should get us a
minimal dump when trying to dump a batch that results in a GPU hang.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| c4089d444a1736dba0c3d9c389ac216ce8711da8 |
|
30-Dec-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen7: Use the updated interface for SO write pointer resetting.
The new kernel patch I submitted makes the interface opt-in, so all
batchbuffers aren't preceded by the 4 MI_LOAD_REGISTER_IMMs. This
requires the updated i915_drm.h present in libdrm 2.4.30.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| f2f14bc4a9a408b1d7cb2b04e8049f951ffb431e |
|
22-Dec-2011 |
Paul Berry <stereotype441@gmail.com> |
i965 Gen6+: Invalidate VF address-based cache on flush
Although there is not much documentation of this fact, there are in
fact two separate VF caches:
- an "index-based" cache (described in the Sandy Bridge PRM, vol 2
part 1, section 2.1.2 "Vertex Cache"). This cache stores URB
handles of vertex shader outputs; its purpose is to avoid redundant
invocations of the vertex shader when drawing in random access mode
(e.g. glDrawElements()), and the same vertex index is specified
multiple times. It is automatically invalidated between
3D_PRIMITIVE commands and between instances within a single
3D_PRIMITIVE command.
- an "address-based" cache (mentioned briefly in vol 2 part 1, section
1.7.4 "PIPE_CONTROL Command"). This cache stores the data read from
vertex buffers; its purpose is to avoid redundant memory accesses
when doing instanced drawing or when multiple 3D_PRIMITIVE commands
access the same vertex data. It needs to be manually invalidated
whenever new data is written to a buffer that is used for vertex
data.
Previous to this patch, it was not necessary for Mesa to explicitly
invalidate the address-based cache, because there were no reasonable
use cases in which the GPU would write to a vertex data buffer during
a batch, and inter-batch flushing was taken care of by the kernel.
However, with transform feedback, there is now a reasonable use case:
vertex data is written to a buffer using transform feedback, and then
that data is immediately re-used as vertex input in the next drawing
operation. To make this use case work, we need to flush the
address-based VF cache between transform feedback and the next draw
operation. Since we are already calling
intel_batchbuffer_emit_mi_flush() when transform feedback completes,
and intel_batchbuffer_emit_mi_flush() is intended to invalidate all
caches, it seems reasonable to add VF cache invalidation to this
function.
As with commit 63cf7fad13fc9cfdd2ae7b031426f79107000300 (i965: Flush
pipeline on EndTransformFeedback), this is not an ideal solution. It
would be preferable to only invalidate the VF cache if the next draw
call was about to consume data generated by a previous draw call in
the same batch. However, since we don't have the necessary dependency
tracking infrastructure to figure that out right now, we have to
overzealously invalidate the cache.
Fixes Piglit test "EXT_transform_feedback/immediate-reuse".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| c3161b629f342b21756f4fdb4414417b82d3e033 |
|
10-Dec-2011 |
Paul Berry <stereotype441@gmail.com> |
i965 gen6+: Make intel_batchbuffer_emit_mi_flush() actually flush.
Previous to this patch, the function intel_batchbuffer_emit_mi_flush()
was a bit of a misnomer. On Gen4+, when not using the blit engine, it
didn't actually flush the pipeline--it simply generated a PIPE_CONTROL
command with the necessary bits set to flush GPU caches. This was
usually sufficient, since in most situations where
intel_batchbuffer_emit_mi_flush() was called, all we really care about
was ensuring cache coherency.
However, with the advent of OpenGL 3.0, there are two cases in which
data output by one stage of the pipeline might be consumed, in a later
draw operation, by an earlier stage of the pipeline:
(a) When using textures in the vertex shader.
(b) When using drawing with a vertex buffer that was previously
generated using transform feedback.
This patch addresses case (a) by changing
intel_batchbuffer_emit_mi_flush() so that on Gen6+, it sets the
PIPE_CONTROL_CS_STALL bit (this forces the pipeline to actually
flush). (Case (b) will be addressed by the next patch in the series).
This is not an ideal solution--in a perfect world, the driver would
have some buffer dependency tracking so that we would only have to
flush the pipeline in the two cases above. Until that dependency
tracking is implemented, however, it seems prudent to have
intel_batchbuffer_emit_mi_flush() actually flush the pipeline, so that
we get correct rendering, at the expense of a (hopefully small)
performance hit.
The change is only applied to Gen6+, since at the moment only Gen6+
supports the OpenGL 3.0 features that make a full pipeline flush
necessary.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| da8f052560120010b7f37a300f03c0847cca3aa5 |
|
22-Oct-2011 |
Eric Anholt <eric@anholt.net> |
intel: Return error value from intel_batchbuffer_flush().
This will let the caller do something sensible on error, if it cares.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 3faf56ffbdebef04345ebb1fa8e0d50b4beeedb2 |
|
22-Oct-2011 |
Eric Anholt <eric@anholt.net> |
intel: Add an interface for saving/restoring the batchbuffer state.
This will be used to avoid the prepare() step in the i965 driver's
state setup. Instead, we can just speculatively emit the primitive
into the batchbuffer, then check if the batch is too big, rollback and
flush, and replay the primitive.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| db364a8af0d19e4032ac44635834737017e1051c |
|
22-Oct-2011 |
Eric Anholt <eric@anholt.net> |
i915: Move the always_flush_cache code to triangle emit.
This could have broken always_flush_cache on i965, since
reserved_space doesn't reflect the size of the workaround flushes, and
we might run out of space. This should make always_flush_cache more
useful on pre-i965, anyway (since the point is to flush around each
draw call, even within a batchbuffer).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 2e5a1a254ed81b1d3efa6064f48183eefac784d0 |
|
07-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
intel: Convert from GLboolean to 'bool' from stdbool.h.
I initially produced the patch using this bash command:
for file in {intel,i915,i965}/*.{c,cpp,h}; do [ ! -h $file ] && sed -i
's/GLboolean/bool/g' $file && sed -i 's/GL_TRUE/true/g' $file && sed -i
's/GL_FALSE/false/g' $file; done
Then I manually added #include <stdbool.h> to fix compilation errors,
and converted a few functions back to GLboolean that were used in core
Mesa's function pointer table to avoid "incompatible pointer" warnings.
Finally, I cleaned up some whitespace issues introduced by the change.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chad Versace <chad@chad-versace.us>
Acked-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| e9adfa2ba1af9c3579b25327335c47118b6c7c3f |
|
06-Oct-2011 |
Chad Versace <chad@chad-versace.us> |
intel: Assert that no batch is emitted if a region is mapped
What I would prefer to assert is that, for each region that is currently
mapped, no batch is emitted that uses that region's bo. However, it's much
easier to implement this big hammer.
Observe that this requires that the batch flush in intel_region_map() be
moved to within the map_refcount guard.
v2: Add comments (borrowed from anholt's reply) explaining why the
assertion is a good idea.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad@chad-versace.us>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8bd27a5b080157cb1d5fc0383ce45574c7b16aa5 |
|
01-Sep-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Emit depth stalls and flushes before changing depth state on Gen6+.
Fixes OpenArena on Gen7. Technically, adding only the first depth stall
fixes it, but the documentation says to do all three, and the Windows
driver seems to do it.
Not observed to fix anything on Gen6 yet.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38863
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 72e0a9226ddf9282a0351e71c0272882473c836d |
|
15-Sep-2011 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
Change strerror(ret) to strerror(-ret).
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 0a00a9a05b357dafae86bf8af879aa601f101eba |
|
04-Sep-2011 |
Yuanhan Liu <yuanhan.liu@linux.intel.com> |
intel: fix build error
Fix a build error introduced by commit 6862b54f:
i965_dri.so.tmp: undefined reference to `strerr'
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 6862b54f4d4e88ef6ebf709ea7798093ec337e2a |
|
02-Sep-2011 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
intel: Give an explanation why we are exiting for debugging.
This could happen in 3 different cases, and ERRNO can explain what
happened. First case would be EIO (gpu hang), second EINVAL (something is
wrong inside the batch), and we also discovered that sometimes it happens
with ENOSPACE. All of those cases are different it it could be worth to at
least know what happened.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 7fdbedac14637b5e8990cb639bd4ddae28c46994 |
|
31-Aug-2011 |
Eric Anholt <eric@anholt.net> |
intel: Upload batchbuffer contents even if INTEL_NO_HW is set.
It is useful for debugging to dump batchbuffers while not actually
executing them.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 185868c9c2e6a31a7313df2dbe29490547b65f61 |
|
25-Jul-2011 |
Eric Anholt <eric@anholt.net> |
i965: Emit texture cache flushes on gen6 along with render cache flushes.
It turns out that internally the texture cache gets flushed in a
couple of cases, particularly around 2D operations mixed with 3D. In
almost all cases one of those happens between rendering to an
FBO-attached texture and rendering from that texture. However, as of
the next patch, glean tfbo (and the new fbo-flushing-2 test) would
manage to get stale texture values because one of those flushes didn't
occur. The intention of this code was always to get the render cache
cleared and ready to be used from the sampler cache (and it does on <=
gen4), so this just catches gen5 up.
This patch was also tested to fix fbo-flushing on gen7.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 407785d0e97abd0cc51a6e360089111973748e7c |
|
19-Jul-2011 |
Eric Anholt <eric@anholt.net> |
i965: Enable the PIPE_CONTROL workaround workaround out of paranoia.
There's scary stuff going on in PIPE_CONTROL internals, and if the
BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do
it because we'll probably never be able to debug it after the fact.
v2: Use stall at scoreboard instead of depth stall, as noted by Ken.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| dc7422405f6f3c201993251e4665bb9ec1b59db0 |
|
19-Jul-2011 |
Eric Anholt <eric@anholt.net> |
i965: Avoid kernel BUG_ON if we happen to wait on the pipe_control w/a BO.
For this and occlusion queries, we're trying to avoid setting
I915_GEM_DOMAIN_RENDER for the write domain, because the data written
is definitely not going through the render cache, but we do need to
tell the kernel that the object has been written. However, with using
I915_GEM_DOMAIN_GTT, the kernel on retiring the batchbuffer sees that
the w/a BO has a write domain of GTT, and puts it on the flushing
list. If something tries to wait for that BO to finish rendering
(such as the AUB dumper reading the contents of BOs), we get into
wait_request (since obj->active) but with a 0 seqno (since the object
is on the flushing list, not actually on a ringbuffer), and BUG_ONs.
To avoid the kernel bug (which I'm hoping to delete soon anyway), just
use I915_GEM_DOMAIN_INSTRUCTION like occlusion queries do. This
doesn't result in more flushing, because we invalidate INSTRUCTION on
every batchbuffer now that we're state streaming, anyway.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 96cdbf43404a65a267065250ae6b29be93071520 |
|
12-Jul-2011 |
Eric Anholt <eric@anholt.net> |
intel: Use the post-execution batchbuffer contents for dumping.
We were missing out on all the relocation changes by dumping what we
subdata()ed in instead of what's there after the kernel finished with
it.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| f6e5230b2614cc91e4c849c07781b2230878d274 |
|
18-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Apply documented workaround for nonpipelined state packets.
Fixes a 100% reproducible GPU hang in topogun-1.06-orc-84k.trace.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 0ab7d6f437f2f7a1b2d84f30497f3c2013b52791 |
|
18-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Limit the workaround flush to once per primitive.
We're about to call this function in a bunch of state emits, so let's
not spam the hardware with flushes too hard.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| dfada714f8db3deea2fea3583c3c166a78db1117 |
|
18-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Use an BO instead of writing to address 0 for PIPE_CONTROL W/A.
This was spectacularly unsafe. On my system, address 0 happens to be
the hardware status page for the render ring, and the first quadword
of that happens to contain nothing we ever look at, but I sure didn't
look forward to having to debug some day when, for example, the kernel
happened to bind the ringbuffer before binding the hwsp.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8f9e8d79c8c180e4254d01c688969d6d45386891 |
|
18-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Factor the PIPE_CONTROL workaround to a separate function.
We're need this workaorund a lot more than we're currently doing, so
let's reuse it.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 23b6f9606dc247488835745668b3686218612536 |
|
31-May-2011 |
Eric Anholt <eric@anholt.net> |
intel: Implement glFinish() correctly by waiting on all previous rendering.
Before, we were waiting for (most of) the current framebuffer to be
done, which is not quite the same thing.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| aa3e1c25d3e4fc7e79236c717deaa838182e68c9 |
|
25-Apr-2011 |
Eric Anholt <eric@anholt.net> |
Revert "intel: use throttle ioctl for throttling"
This reverts commit 50ade6ea697953bb17e3ca7210515fbd0411cd1e.
Fixes jerky rendering again on apps that don't block on the GPU per
frame and are GPU bound (e.g. 3DMMES on Ironlake). The whole point of
this complicated throttle scheme is to wait on frame n-1 to have
started rendering before starting frame n's rendering. Otherwise, the
GPU-bound app will race ahead and call the GL to draw many
nearly-identical frames, then >0ms later get stuck waiting for them
(all dispatched at about the same time) to retire, then render a new
batch of nearly-identical frames.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 6584d0cd4fa3a3255a4c0962f31338601df705cb |
|
30-Mar-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Remove the unrelaxed relocation assertion
Now that we purposefully generate delta that point outside of the target
buffer, the assertion has outlived its usefulness.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 50ade6ea697953bb17e3ca7210515fbd0411cd1e |
|
30-Dec-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: use throttle ioctl for throttling
Rather than waiting on the first batch after the last swapbuffers to be
retired, call into the kernel to wait upon the retirement of any request
less than 20ms old. This has the twofold advantage of (a) not blocking
any other clients from utilizing the device whilst we wait and (b) we
attain higher throughput without overloading the system.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| aac120977d1ead319141d48d65c9bba626ec03b8 |
|
20-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
i965: Move repeat-instruction-suppression to batchbuffer core
Move the tracking of the last emitted instructions into the core
batchbuffer routines and take advantage of the shadow batch copy to
avoid extra memory allocations and copies.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8d68a90e225d831a395ba788e425cb717eec1f9a |
|
10-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: use pwrite for batch
It's faster. Not only is the memcpy more efficiently performed in the
kernel (making up for the system call overhead), but by not using mmap
we remove the greater overhead of tracking the vma of every batch.
And it means we can read back from the batch buffer without incurring
the cost of a uncached read through the GTT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8a9e67b8df9836408270a4bc3660ec45b622ae56 |
|
10-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Buffered upload
Rather than performing lots of little writes to update the common bo
upon each update, write those into a static buffer and flush that when
full (or at the end of the batch). Doing so gives a dramatic performance
improvement over and above using mmaped access.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| e476e122207e6195a16a8c7d2cab90eeba227934 |
|
08-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Pack dynamic draws together
Dynamic arrays have the tendency to be small and so allocating a bo for
each one is overkill and we can exploit many efficiency gains by packing
them together.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 845d651cf686ba885dffd9e05df971fa68c3431a |
|
23-Dec-2010 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
i965: Use MI_FLUSH_DW for blt ring flush on sandybridge
Old MI_FLUSH command is deprecated on sandybridge blt.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| c27285610c9f9b50d06bf0f2725da195937cb48d |
|
13-Dec-2010 |
Eric Anholt <eric@anholt.net> |
i965: Add support for using the BLT ring on gen6.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 4ac2f09e2034d8940a0ce9426a8d5c5d74bc63bd |
|
03-Dec-2010 |
Eric Anholt <eric@anholt.net> |
intel: Add an env var override to execute for a different GPU revision.
Sometimes I'm on the train and want to just read what's generated
under INTEL_DEBUG=vs,wm for some code on another generation. Or, for
the next gen enablement we'll want to dump aub files before we have
the actual hardware. This will let us do that.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| bb1540835056cdea5db6f55b19c0c87358f14cd1 |
|
03-Nov-2010 |
Eric Anholt <eric@anholt.net> |
intel: Annotate debug printout checks with unlikely().
This provides the optimizer with hints about code hotness, which we're
quite certain about for debug printouts (or, rather, while we
developers often hit the checks for debug printouts, we don't care
about performance while doing so).
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 689def8bbcd2851adc89bebc84fd99bd627ff173 |
|
20-Sep-2010 |
Eric Anholt <eric@anholt.net> |
intel: For batch, use GTT mapping instead of writing to a malloc and copying.
No measurable performance difference on cairo-perf-trace, but
simplifies the code and should have cache benefit in general.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 18c3b754f974751550dc9505d50535365beac8f3 |
|
17-Sep-2010 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
i965: sandybridge pipe control workaround before write cache flush
Must issue a pipe control with any non-zero post sync op before
write cache flush = 1 pipe control.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| e72b87736d8453e79bb6da48ba4cfcc2e97c8e14 |
|
08-Jul-2010 |
Eric Anholt <eric@anholt.net> |
intel: Update intel_decode.c from intel-gpu-tools.
This came from commit cf255e382d147fe3ca450f0dcec3525190e7dcbc
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 321014156b3f7842a84d9b9915389c9f6f6486f5 |
|
11-Mar-2010 |
Eric Anholt <eric@anholt.net> |
i965: Add support for streaming indirect state rather than caching objects.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| df3c1a563f3d76b07ab82c7b230b0030452f36ff |
|
07-Jun-2010 |
Eric Anholt <eric@anholt.net> |
intel: Convert remaining dri_bo_emit_reloc to drm_intel_bo_emit_reloc.
The new API makes so much more sense, I'd like to forget how the old
one worked.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 34474fa4119378ef9fbb9fb557cc19c0a1ca1f7e |
|
07-Jun-2010 |
Eric Anholt <eric@anholt.net> |
intel: Change dri_bo_* to drm_intel_bo* to consistently use new API.
The slightly less mechanical change of converting the emit_reloc calls
will follow.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 22409756d4ed941f2ec6729ab0c312149749106f |
|
07-Jun-2010 |
Eric Anholt <eric@anholt.net> |
intel: Clean up stale comments in intel_batchbuffer.c.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 754fcd605b200c1983d2840931b7cf8d638116df |
|
07-Jun-2010 |
Eric Anholt <eric@anholt.net> |
intel: Remove the non-gem paths for batchbuffer upload.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8accf0a891c85c7d747c5f7f4a4d8a99adb91b2a |
|
31-May-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: Initialize batch->reserved_space on allocation
Fixes the assert (and buffer overrun):
glknots: intel_batchbuffer.c:164: _intel_batchbuffer_flush: Assertion
'used >= batch->buf->size' failed.
Reported in bug:
Bug 28274 - xscreensaver's glknots hangs GPU (945GME/Pineview)
https://bugs.freedesktop.org/show_bug.cgi?id=28274
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 9390af0d9636ed8e985ff22cdbbbf9b12c3a7586 |
|
18-May-2010 |
Zou Nan hai <nanhai.zou@intel.com> |
i965: fix PIPE_CONTROL command for gen6.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8f61114907669b2134fbdc1a794926035486e8df |
|
24-May-2010 |
Eric Anholt <eric@anholt.net> |
i965: Don't PIPE_CONTROL instruction cache flush.
This is a workaround for Ironlake errata. The emit_mi_flush is used
for a few purposes:
1) Flushing write caches for RTT (including blit to texture)
2) Pipe fencing for sync objects
3) Spamming cache flushes to track down cache flush bugs
Spamming cache flushes seems less important than following the docs,
and we should probably do that with a different mechanism than the one
for render cache flushes.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| e67c338b415c983bee570e6644b9684d8d1fc99b |
|
19-May-2010 |
Kristian Høgsberg <krh@bitplanet.net> |
intel: Throttle after doing copyregion/swapbuffers round trip
Before we would throttle in the flush callback prior to round-tripping
to the server to do copyregion or swapbuffer. Now, instead just note
that we need to throttle and do it in intel_prepare_render(), which
will be called after receiving the response from the server but before
we start rendering the next frame. Even if the server also throttles
us in swapbuffer, this just makes the throttling a no-op when we hit
intel_prepare_render(). With that we can drop the
using_dri2_swapbuffers hack and just always throttle.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| dfb7b86e633ae9b656f5a15932a220b04cc092d5 |
|
18-May-2010 |
Eric Anholt <eric@anholt.net> |
i965: Revert accidental debug change in 562e2d114ec0cba8
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 562e2d114ec0cba879463980522d1d54af9444e6 |
|
14-May-2010 |
Eric Anholt <eric@anholt.net> |
i965: Support INTEL_DEBUG=clip to dump the clip program.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 342a7f23bf76e21b049cba9ab97bf4aa640a5bfd |
|
05-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Move the assertions about reloc delta from the macros to the function.
Cuts another 1800 bytes from the driver.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 06d1472ffa0648efa9374fa227894fbf0b0be054 |
|
03-Mar-2010 |
Eric Anholt <eric@anholt.net> |
i915: Tell the kernel when we actually need fence registers on our BOs.
This improves tiled texture performance of OA on my 945 from 25.3fps
to 29.0fps, whereas untiled is 28.2fps, by avoiding stalls for fence
register changes.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| fc26f894babc47dd3a823bd4d63ee4d8ee0dad04 |
|
25-Feb-2010 |
Eric Anholt <eric@anholt.net> |
intel: Fix up INTEL_NO_HW support.
This was accidentally (it seems) deleted in
5203b7227ccb6b618fa42f08434d4a3cf123dca2
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 15904c057beec3029a8ed2035d7ba50f9414943d |
|
22-Feb-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
intel: assert that we do not overflow the batch buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| b76164dcedad257f37af57358b102e14fdea8381 |
|
20-Feb-2010 |
Vinson Lee <vlee@vmware.com> |
intel: Silence compiler format warnings.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 298be2b028263b2c343a707662c6fbfa18293cb2 |
|
19-Feb-2010 |
Kristian Høgsberg <krh@bitplanet.net> |
Replace the _mesa_*printf() wrappers with the plain libc versions
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 41f4d82ba8e2497d9fe27f55cb1b8707862fed46 |
|
27-Jan-2010 |
Eric Anholt <eric@anholt.net> |
intel: Clean up stale comments about cliprects.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 5e1851b144a97bd577409dd5c6f3f6f45b4ff56f |
|
20-Jan-2010 |
Eric Anholt <eric@anholt.net> |
i965: Remove unnecessary malloc/free in VS binding table setup.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 5203b7227ccb6b618fa42f08434d4a3cf123dca2 |
|
02-Jan-2010 |
Kristian Høgsberg <krh@bitplanet.net> |
intel: Drop batchbuffer cliprect_mode tracking
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 01dc463e5d5513e059eea601710cd4babe02610d |
|
02-Jan-2010 |
Kristian Høgsberg <krh@bitplanet.net> |
intel: Drop LOCK/UNLOCK_HARDWARE()
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8 |
|
18-Nov-2009 |
Eric Anholt <eric@anholt.net> |
intel: Remove non-GEM support.
This really isn't supported at this point. GEM's been in the kernel for
a year, and the fake bufmgr never really worked.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| a376e5c48237be0300bce6702ed947086d3ee23f |
|
18-Nov-2009 |
Eric Anholt <eric@anholt.net> |
intel: Consistently use no_batch_wrap in intel_context struct.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8e0f40d28777f1ae599a95312788fe29a0515a0d |
|
04-Nov-2009 |
Eric Anholt <eric@anholt.net> |
intel: Use PIPE_CONTROL on gen4 hardware for doing pipeline flushing.
This should do all the things that MI_FLUSH did, but it can be pipelined
so that further rendering isn't blocked on the flush completion unless
necessary.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| fb0084e69e3326b49aca8ca004e19acb7f8c8555 |
|
26-Oct-2009 |
Eric Anholt <eric@anholt.net> |
intel: Clean up merge leftover from the DRI2 swap throttling.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 1f713059934c2365a42aadfdca49213b36a7de90 |
|
05-Aug-2009 |
Brian Paul <brianp@vmware.com> |
Merge branch 'mesa_7_5_branch'
Conflicts:
src/mesa/main/state.c
|
| f5f8be8bb2dae91e0eb748b6f062eeb345605063 |
|
04-Aug-2009 |
Brian Paul <brianp@vmware.com> |
intel: Wait on the last swapbuffers to complete before queuing a new one.
This fixes jerkiness in doom3 and other apps since the kernel change to
throttle less absurdly, which led to a thundering herd of frames.
Because this is a rather minimal fix, there is at least one downside: If
the whole scene completes in one batchbuffer, we'll end up stalling the GPU.
Thanks to Michel Dänzer for suggesting using glFlush to signal frame end
instead of going to all the effort of adding a new DRI2 extension.
(cherry picked from master, commit 0828579a658af01a64b5e699175dc9bbbedcd685)
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 0828579a658af01a64b5e699175dc9bbbedcd685 |
|
21-Jul-2009 |
Eric Anholt <eric@anholt.net> |
intel: Wait on the last swapbuffers to complete before queuing a new one.
This fixes jerkiness in doom3 and other apps since the kernel change to
throttle less absurdly, which led to a thundering herd of frames.
Because this is a rather minimal fix, there is at least one downside: If
the whole scene completes in one batchbuffer, we'll end up stalling the GPU.
Thanks to Michel Dänzer for suggesting using glFlush to signal frame end
instead of going to all the effort of adding a new DRI2 extension.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 3927874d9c7fafb61651d0fc69547c8e010181f5 |
|
29-Jun-2009 |
Eric Anholt <eric@anholt.net> |
intel: Make LOCK_HARDWARE recursive to avoid hand-rolling recursiveness.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| f3687284c12f34268172b9c60e2effd697162129 |
|
06-Mar-2009 |
Eric Anholt <eric@anholt.net> |
intel: Add always_flush_cache driconf option for debugging cache flush failure.
I keep wanting to hack this knob in as a one-time thing, so it seemed useful
to have all the time.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 09623fe551771031ed02ba7542c94bdbdd83ecec |
|
11-Nov-2008 |
Xiang, Haihao <haihao.xiang@intel.com> |
intel: reset cliprect_mode to IGNORE_CLIPRECTS.
This ensures all batchbuffers have a same cliprect mode after calling
_intel_batchbuffer_flush even if there aren't invalid commands in the
current batch buffer. (fix bug#18362).
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 0cade4de4f74f6b0e86fb6622e2fc370c73fd840 |
|
20-Oct-2008 |
Eric Anholt <eric@anholt.net> |
intel: Don't keep intel->pClipRects, and instead just calculate it when needed.
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.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 35fd72756a05463568d94862f4fcd234903e1204 |
|
08-Sep-2008 |
Eric Anholt <eric@anholt.net> |
intel: track move of bo_exec from drivers to bufmgr.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 3628185f566e178a12b493fb89abf52b4b281f99 |
|
06-Sep-2008 |
Eric Anholt <eric@anholt.net> |
intel: track bufmgr move to libdrm_intel and bufmgr_fake irq emit/wait change.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 7e0bbdcf033981282978554c2e68ce48b55aa291 |
|
04-Sep-2008 |
Eric Anholt <eric@anholt.net> |
intel: Move the bufmgr back to the screen.
Mesa requires that we be able to share objects between contexts, which means
that the objects need to be created by the same bufmgr, and the bufmgr
internally requires pthread protection for thread safety.
Rely on the bufmgr having appropriate locking.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| f75843a517bd188639e6866db2a7b04de3524e16 |
|
24-Aug-2008 |
Dave Airlie <airlied@linux.ie> |
Revert "Revert "Merge branch 'drm-gem'""
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a |
|
24-Aug-2008 |
Dave Airlie <airlied@linux.ie> |
Revert "Merge branch 'drm-gem'"
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| d2796939f18815935c8fe1effb01fa9765d6c7d8 |
|
08-Aug-2008 |
Eric Anholt <eric@anholt.net> |
intel-gem: Update to new check_aperture API for classic mode.
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.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| a42dac187973cbc17be6c59db89264cbc935ab91 |
|
24-Jun-2008 |
Eric Anholt <eric@anholt.net> |
i915: Accumulate the VB into a local buffer and subdata it in.
This lets GEM use pwrite, for an additional 4% or so speedup.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 4b5b008d54e86ac4f0a2176429d062100978ca8c |
|
03-Jun-2008 |
Eric Anholt <eric@anholt.net> |
[intel] Convert drivers to using libdrm bufmgr code.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 145523ba3acb95a9ff390430a9e0a3fa958cae1b |
|
11-May-2008 |
Keith Packard <keithp@keithp.com> |
[intel] update GEM api. Add bo_subdata and bo_get_subdata driver hooks.
Track DRM GEM name changes.
Add driver hooks for bo_subdata and bo_get_subdata so that GEM can use pread
and pwrite.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| fda5687241f4ce5cab3bf2eac437b52d4b37dd10 |
|
08-May-2008 |
Keith Packard <keithp@keithp.com> |
[intel] intel_batchbuffer_flush using uninit 'used' to check for buffer empty
Make sure 'used' tracks the right value through the whole function.
Also, use GLint for intel_batchbuffer_space in case we do bad things
in the future.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| ab50ddaa9173ae108833db0edb209045788efc41 |
|
07-May-2008 |
Eric Anholt <eric@anholt.net> |
GEM: Make dri_emit_reloc take GEM domain flags instead of TTM flags.
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.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8b2a7f08bc446deef497f2a0d3b54d9b70bdaf9c |
|
07-May-2008 |
Eric Anholt <eric@anholt.net> |
GEM: Don't emit an extra MI_FLUSH in the batch since GEM handles it.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 1f810b85b1e9393c8e606d2f28250cbb19cf916b |
|
05-May-2008 |
Eric Anholt <eric@anholt.net> |
Make intel_{batch,exec}_ioctl return an error code so we can recover better.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| eb10cdc838fc31ea2cf59f556f6f7d8b072f5bae |
|
02-May-2008 |
Eric Anholt <eric@anholt.net> |
[intel] Fix build for GEM. TTM is now disabled, and fencing is gone.
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).
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 89bba44e969f15bf20da6d700c493237b095a588 |
|
02-May-2008 |
Eric Anholt <eric@anholt.net> |
Add intel_bufmgr_gem for new graphics execution manager.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 3323ccb803282dddcf1e403df33d00eaa0fbd0f8 |
|
02-May-2008 |
Eric Anholt <eric@anholt.net> |
[intel] Warnings fixes.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 7cc7ff7051d427ff45b4d7d3664e2eecd13d0e13 |
|
16-Apr-2008 |
Dave Airlie <airlied@panoply-rh.(none)> |
intel/fake_bufmgr: Attempt to restrict references to objects in a 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.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 8517079cbcbbf31291b05420f3b776df712dfd47 |
|
14-Jan-2008 |
Eric Anholt <eric@anholt.net> |
[i915] Fix driver from cliprects changes, and clean up state emission.
The fix for pageflipping with cliprects ended up causing a batch flush at
an inopportune time, which is fixed by moving it up.
Additionally, the recovery code for handling batch wraps at bad times is
replaced by just checking for the space up front, and using a no_batch_wrap
assert like on 965 to make sure that we weren't wrong about how much space that
was.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| bb73cf9ec093d734cbed956d843ef6c2982141ef |
|
15-Jan-2008 |
Kristian Høgsberg <krh@temari.boston.redhat.com> |
[i915] Prevent recursive batchbuffer flushing.
Workaround for recursive batchbuffer flushing: If the window is
moved, we can get into a case where we try to flush during a
flush. What happens is that when we try to grab the lock for
the first flush, we detect that the window moved which then
causes another flush (from the intel_draw_buffer() call in
intelUpdatePageFlipping()). To work around this we reset the
batchbuffer tail pointer before trying to get the lock. This
prevent the nested buffer flush, but a better fix would be to
avoid that in the first place.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| ab2933df65628d8f1f0a3f49129442bc8d2c3a2b |
|
10-Jan-2008 |
Eric Anholt <eric@anholt.net> |
[intel] Only flush batch when changing draw buffers, not every cliprect update.
The previous code would reference freed memory on window moves.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| a04b632350e5d0e9994fc667afc59407a39da0ba |
|
10-Jan-2008 |
Eric Anholt <eric@anholt.net> |
[intel] Add more cliprect modes to cover other meanings for batch emits.
The previous change gave us only two modes, one which looped over the batch
per cliprect (3d drawing) and one that didn't (state updeast).
However, we really want 4:
- Batch doesn't care about cliprects (state updates)
- Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing)
- Batch needs to be executed just once (region fills, copies, etc.)
- Batch already includes cliprect handling, and must be flushed by unlock time
(copybuffers, clears).
All callers should now be fixed to use one of these states for any batchbuffer
emits. Thanks to Keith Whitwell for pointing out the failure.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 5f86ae057a645c03dc1e0c51c2fb1b2628a50e0a |
|
09-Jan-2008 |
Eric Anholt <eric@anholt.net> |
[intel] Rename lost_hardware vtbl entry to new_batch.
Both drivers have ended up relying on lost_hardware being called after each
batch buffer, so update the name. This removes one of the calls on 965 whic
h was outside of the batchbuffer handling code and just duplicating what had
already happened through batchbuffer handling.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| beddf653a914903156712aa472b5deaddb7bbaed |
|
09-Jan-2008 |
Eric Anholt <eric@anholt.net> |
[intel] Clean up cliprect handling in intel drivers.
In particular, batch buffers are no longer flushed when switching from
CLIPRECTS to NO_CLIPRECTS or vice versa, and 965 just uses DRM cliprect
handling for primitives instead of trying to sneak in its own to avoid the
DRM stuff. The disadvantage is that we will re-execute state updates per
cliprect, but the advantage is that we will be able to accumulate larger
batch buffers, which were proving to be a major overhead.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 7c71ef3a3d0cf2620525f468960cdc76a0fb0d33 |
|
12-Dec-2007 |
Eric Anholt <eric@anholt.net> |
[intel] Move bufmgr back to context instead of screen, fixing glthreads.
Putting the bufmgr in the screen is not thread-safe since the emit_reloc
changes. It also led to a significant performance hit from pthread usage
for the attempted thread-safety (up to 12% of a cpu spent on refcounting
protection in single-threaded 965). The motivation had been to allow
multi-context bufmgr sharing in classic mode, but it wasn't worth the cost.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| aeca22f97c5650108a315063ea76ad2204bb2ef5 |
|
06-Dec-2007 |
Keith Packard <keithp@keithp.com> |
Use previous buffer offsets to compute proposed relocations
This takes advantage of the DRM_BO_HINT_PRESUMED_OFFSET change and allows
the kernel to avoid mapping and re-writing buffers when relocations occur.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| e3a6e60040b7f6ea7965e52f8f9881ed31e0347c |
|
08-Dec-2007 |
Eric Anholt <eric@anholt.net> |
[965] Convert the driver to dri_bufmgr interface and enable TTM.
This is currently believed to work but be a significant performance loss.
Performance recovery should be soon to follow.
The dri_bo_fake_disable_backing_store() call was added to allow backing store
disable like bufmgr_fake.c did, which is a significant performance win (though
it's missing the no-fence-subdata part).
This commit is a squash merge of the 965-ttm branch, which had some history
I wanted to avoid pulling due to noisiness and brokenness at many points
for git-bisecting.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 556cf9abff75eaa56c3ea11f1c59cb04d30c0b92 |
|
01-Dec-2007 |
Eric Anholt <eric@anholt.net> |
[intel] Move batch bo_unmap from TTM code to shared, and add more asserts.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| a8fee3a498c8c4966d57a5273408477f3aa3ce73 |
|
15-Nov-2007 |
Keith Whitwell <keith@tungstengraphics.com> |
i915: Catch cases where not all state is emitted for a new batchbuffer.
This could lead to incorrect rendering or even lockups.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 3bd07ba0d4f759e3a17e2a5ed51086b44705a482 |
|
16-Nov-2007 |
Eric Anholt <eric@anholt.net> |
[i915] Add INTEL_DEBUG=sync debug flag to wait for fences after making them.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| f7e0513d700167a7eff39e40c855027096f1db1d |
|
25-Oct-2007 |
Eric Anholt <eric@anholt.net> |
[i915] Reenable batchbuffer debug under INTEL_DEBUG=bat.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| 77a5bcaff43df8d54e0e0ef833726e4b41d7eb36 |
|
07-Nov-2007 |
Eric Anholt <eric@anholt.net> |
[intel] Move over files that will be shared with 965-fbo work.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| e886ae4c58bc98897d6901e3f30deea008bc7f8a |
|
28-Sep-2007 |
Eric Anholt <eric@anholt.net> |
Revert "WIP 965 conversion to dri_bufmgr."
This reverts commit b2f1aa2389473ed09170713301b042661d70a48e.
Somehow I ended up with my branch's save-this-while-I-work-on-master commit
actually on master.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|
| b2f1aa2389473ed09170713301b042661d70a48e |
|
27-Sep-2007 |
Eric Anholt <eric@anholt.net> |
WIP 965 conversion to dri_bufmgr.
/external/mesa3d/src/mesa/drivers/dri/intel/intel_batchbuffer.c
|