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
|