aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/intel_batchbuffer.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: batchbuffer: write correct canonical offset with softpinLionel Landwerlin2018-07-181-1/+2
| | | | | | | | | | | | | Addresses in the command streams should be in canonical form (i.e bit[63:48] == bit[47]). If the [bo->gtt_offset, bo->gtt_offset + target_offset] range contains the address 0x800000000000, the current code will fail that criteria. v2: Fix missing include (Lionel) Fixes: 1c9053d0765dc6 ("i965: Prepare batchbuffer module for softpin support.") Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Prepare batchbuffer module for softpin support.Kenneth Graunke2018-06-041-3/+35
| | | | | | | | | | | | | | | | | | | | If EXEC_OBJECT_PINNED is set, we don't want to emit any relocations. We simply want to add the BO to the validation list, and possibly mark it as writeable. The new brw_use_pinned_bo() interface does just that. To avoid having to make every caller consider both the relocation and softpin cases, we make emit_reloc() call brw_use_pinned_bo() when given a softpinned buffer. We also can't grow buffers that are softpinned - the mechanism places a larger BO at the same offset as the original, which requires moving BOs around in the VMA. With softpin, we only allocate enough VMA for the original size of the BO. v2: Assert that BOs aren't pinned if the kernel says we should move them (feedback from Chris Wilson) Reviewed-by: Scott D Phillips <[email protected]>
* i965: Fix batch-last mode to properly swap BOs.Kenneth Graunke2018-06-041-0/+5
| | | | | | | | | | | | | | | On pre-4.13 kernels, which don't support I915_EXEC_BATCH_FIRST, we move the validation list entry to the end...but incorrectly left the exec_bo array alone, causing a mismatch where exec_bos[0] no longer corresponded with validation_list[0] (and similarly for the last entry). One example of resulting breakage is that we'd update bo->gtt_offset based on the wrong buffer. This wreaked total havoc when trying to use softpin, and likely caused unnecessary relocations in the normal case. Fixes: 29ba502a4e28471f67e4e904ae503157087efd20 (i965: Use I915_EXEC_BATCH_FIRST when available.) Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Remove ring switching entirelyJason Ekstrand2018-05-221-58/+34
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove support for the BLT ringJason Ekstrand2018-05-221-9/+3
| | | | | | | We still support the blitter on gen4-5 but it's on the same ring as 3D. Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Introduce a "memory zone" concept on BO allocation.Kenneth Graunke2018-05-221-5/+10
| | | | | | | | | | | | | | | | | We're planning to start managing the PPGTT in userspace in the near future, rather than relying on the kernel to assign addresses. While most buffers can go anywhere, some need to be restricted to within 4GB of a base address. This commit adds a "memory zone" parameter to the BO allocation functions, which lets the caller specify which base address the BO will be associated with, or BRW_MEMZONE_OTHER for the full 48-bit VMA. Eventually, I hope to create a 4GB memory zone corresponding to each state base address. Reviewed-by: Scott D Phillips <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Dump validation list on INTEL_DEBUG=bat,submit.Kenneth Graunke2018-05-081-1/+3
| | | | | | | | | | This is really useful when debugging any sort of buffer management issues, so just printing it during INTEL_DEBUG=bat,submit seems reasonable. With bat, we're already spamming so much output that it doesn't really hurt. With submit, it's still easy to grep for the older information, and the new information is nice too. Reviewed-by: Scott D Phillips <[email protected]>
* intel: decoder: limit to the number decoded lines from VBOLionel Landwerlin2018-05-021-0/+1
| | | | | | | | By default we set no limit, but the debug batch decoder in i965 sets it to 100. Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Reuse batch decoder infrastructure rather than open coding it.Kenneth Graunke2018-05-021-222/+52
| | | | | | | | | With the new callback, Jason's newer batch decoder infrastructure should be able to do just as well as the old open coded INTEL_DEBUG=bat handling, with much less code. If there are any limitations, we'd like to improve the common code rather than doing one-off hacks here. Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Allocate shadow batches to explicitly be the BO size.Kenneth Graunke2018-05-021-7/+5
| | | | | | | | | | | | | | This unfortunately makes it malloc/realloc on every new batch, rather than once at startup. But it ensures that the shadow buffer's size will absolutely match the BO size. Otherwise, as we tune BATCH_SZ/STATE_SZ or bufmgr cache bucket sizes, we may get a BO size that's rounded up, and fail to allocate the shadow buffer large enough. This doesn't fix any bugs today, as BATCH_SZ/STATE_SZ are the size of a cache bucket, but it's better to be safe than sorry. Reported-by: James Xiong <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Let batchbuffers be placed anywhere in the 48-bit address space.Kenneth Graunke2018-04-301-1/+1
| | | | | | | | | We were trying to mark batch buffers with EXEC_OBJECT_CAPTURE, and accidentally stomped EXEC_OBJECT_SUPPORTS_48B_ADDRESS in the process. There's no reason to restrict batch buffers to the lower 4GB. Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Fix shadow batches to be the same size as the real BO.Kenneth Graunke2018-04-181-1/+4
| | | | | | | | | | | | | | brw_bo_alloc may round up our allocation size to the next bucket size. In this case, we would malloc a shadow buffer that was the original intended size, but use bo->size (the larger size) for all of our checks. This could cause us to run off the end of the shadow buffer. v2: Actually use the new BO size (caught by Lionel) Reported-by: James Xiong <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Fixes: c7dcee58b5fe183e1653c13bff6a212f0d157b29 (i965: Avoid problems from referencing orphaned BOs after growing.)
* i965: Use %x instead of %u in debug print.Kenneth Graunke2018-04-061-1/+1
| | | | | I mistakenly printed out the address as 0x<decimal number> instead of printing a proper hex number. This was...surprising.
* i965: Extend the negative 32-bit deltas to 64-bitsSergii Romantsov2018-04-031-1/+1
| | | | | | | | | | | | | | | | | | Gen8+ use 48-bit address relocations so need to extend the sign to 64-bit return value. Without it we have higher bits zeroed and missing the negavive values. Haswell and older use 32-bit deltas so are unaffected by this issue. v2: used int32_t fucntion parameter instead of explicit type conversion. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408 Signed-off-by: Sergii Romantsov <[email protected]> Tested-by: Andriy Khulap <[email protected]> Tested-by: Stuart Young <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "18.0 17.3" <[email protected]>
* i965: Drop unnecessary bo->align field.Kenneth Graunke2018-03-271-1/+0
| | | | | | | | bo->align is always 0; there's no need to waste 8 bytes storing it. Thanks to C99 initializers zeroing fields, we can completely drop the only read of the field altogether. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Drop unused alignment parameter from brw_bo_alloc().Kenneth Graunke2018-03-271-2/+2
| | | | | | brw_bo_alloc no longer uses this parameter, so there's no point. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Generalize intel_upload.c to support multiple uploaders.Kenneth Graunke2018-03-021-1/+1
| | | | | | | | | | | | | I'd like to reuse the upload logic for a new program cache, but the buffers will need to have a different lifetime than the default uploader, and also some address space restrictions. So, we can't use a single uploader for both situations - we'll need two of them. This creates a public 'uploader' structure, and adjusts the interface to take an uploader rather than always using brw->upload. It should have no functional change at the moment. Reviewed-by: Chris Wilson <[email protected]>
* i965: Allow 48-bit addressing on Gen8+.Kenneth Graunke2018-03-011-0/+15
| | | | | | | | | | | | | | | | | This allows most GPU objects to use the full 48-bit address space offered by Gen8+ platforms, rather than being stuck with 32-bit. This expands the available GPU memory from 4G to 256TB or so. A few objects - instruction, scratch, and vertex buffers - need to remain pinned in the low 4GB of the address space for various reasons. We default everything to 48-bit but disable it in those cases. Thanks to Jason Ekstrand for blazing this trail in anv first and finding the nasty undocumented hardware issues. This patch simply rips off all of his findings. Reviewed-by: Jordan Justen <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965: Add debugging code to dump the validation list.Kenneth Graunke2018-03-011-0/+22
| | | | | When anything goes wrong with this code, dumping the validation list is a useful way to figure out what's happening.
* i965: Fix RELOC_WRITE typo in brw_store_data_imm64()Andriy Khulap2018-03-011-1/+1
| | | | | | | | | | Fixes: 6c530ad11605 ("i965: Reduce passing 2x32b of reloc_domains to 2 bits") Signed-off-by: Andriy Khulap <[email protected]> Signed-off-by: Vadym Shovkoplias <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Stop restoring the default L3 configuration on Kernel 4.16+.Kenneth Graunke2018-02-171-2/+3
| | | | | | | | | | Kernel 4.16 has proper context isolation, which means we can change the L3 configuration without worrying about that leaking to other newly created contexts, breaking the assumptions of other userspace. So, disable our workaround to reprogram it back to the default. Reviewed-by: Francisco Jerez <[email protected]>
* i965: Delete more misleading comments.Kenneth Graunke2018-01-311-3/+0
| | | | | | | brw_bo_wait_rendering used to take a brw_context pointer for perf_debug messages about stalls. Chris eliminated that in 833108ac14ade91f54cc6e. This message about passing NULL to avoid those warnings is no longer relevant, and just adds confusion. So, drop it.
* i965: Emit PIPE_CONTROL with ISP bit on older platforms.Rafael Antognolli2018-01-291-1/+1
| | | | | | | Emit it on all platforms since gen7. Signed-off-by: Rafael Antognolli <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/gen10: Ignore push constant packets during context restore.Rafael Antognolli2018-01-261-0/+4
| | | | | | | | | | | | | | | | These packets were causing GPU hangs when the context was restored, possibly because they were pointing to BO's that were already unreferenced. So we tell the hardware to ignore such packets after the batch buffer ends, since we know those BO's are not around anymore. This change fixes GPU hangs on CNL. The (partial) solution to this problem so far was to entirely disable push constants on this platform. Signed-off-by: Rafael Antognolli <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: "18.0" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Avoid problems from referencing orphaned BOs after growing.Kenneth Graunke2018-01-191-24/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Growing the batch/state buffer is a lot more dangerous than I thought. A number of places emit multiple state buffer sections, and then write data to the returned pointer, or save a pointer to brw->batch.state.bo and then use it in relocations. If each call can grow, this can result in stale map references or stale BO pointers. Furthermore, fences refer to the old batch BO, and that reference needs to continue working. To avoid these woes, we avoid ever swapping the brw->batch.*.bo pointer, instead exchanging the brw_bo structures in place. That way, stale BO references are fine - the GEM handle changes, but the brw_bo pointer doesn't. We also defer the memcpy until a quiescent point, so callers can write to the returned pointer - which may be in either BO - and we'll sort it out and combine the two properly in the end. v2/v3: - Handle stale pointers in the shadow copy case, where realloc may or may not move our shadow copy to a new address. - Track the partial map explicitly, to avoid problems with buffer reuse where multiple map modes exist (caught by Chris Wilson). v4: - Don't use realloc in the CPU shadow case, it isn't safe. Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need space and can't flush." Reviewed-by: Iago Toral Quiroga <[email protected]> [v3] Reviewed-by: Chris Wilson <[email protected]>
* i965: Pass brw_growing_bo to grow_buffer().Kenneth Graunke2018-01-171-11/+9
| | | | | | Cleaner. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Make a helper for recreating growing buffers.Kenneth Graunke2018-01-171-13/+17
| | | | | | | | | | | Now that we have two of these, we're duplicating a bunch of this logic. The next commit will add more logic, which would make the duplication seem worse. This ends up setting EXEC_OBJECT_CAPTURE on the batch, which isn't necessary (it's already captured), but it should be harmless. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Replace cpu_map pointers with a "use_shadow_copy" boolean.Kenneth Graunke2018-01-171-20/+19
| | | | | | | | Having a boolean for "we're using malloc'd shadow copies for all buffers" is cleaner than having a cpu_map pointer for each. It was okay when we had one buffer, but this is more obvious. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Torch public intel_batchbuffer_emit_dword/float helpers.Kenneth Graunke2018-01-061-2/+2
| | | | | | | | | | | intel_batchbuffer_emit_float is dead code, it should go. intel_batchbuffer_emit_dword only had one user, which had bungled using them by forgetting to call intel_batchbuffer_require_space first. So it seems wise to delete these unsafe helpers. Cc: [email protected] Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Require space for MI_BATCHBUFFER_END.Kenneth Graunke2018-01-061-2/+5
| | | | | | | | | | | intel_batchbuffer_emit_dword doesn't reserve space for the DWord it emits. In the past, we had some reserved batch space to ensure this worked. With the switch to growing batches, we need to actually request space so that we grow if necessary. Fixes: 2c46a67b4138631217141f (i965: Delete BATCH_RESERVED handling.) Cc: [email protected] Reviewed-by: Jason Ekstrand <[email protected]>
* intel/decoder: Take a bit offset in gen_print_groupJason Ekstrand2017-12-141-5/+5
| | | | | | | | | | Previously, if a group was nested in another group such that it didn't start on a dword boundary, we would decode it as if it started at the start of its first dword. This changes things to work even more in terms of bits so that we can properly decode these structs. This affects MOCS, attribute swizzles, and several other things. Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Reorganize batch/state BO fields into a 'brw_growing_bo' struct.Kenneth Graunke2017-11-291-57/+59
| | | | | | | | | | | | | We're about to add more of them, and need to pass the whole lot of them around together when growing them. Putting them in a struct makes this much easier. brw->batch.batch.bo is a bit of a mouthful, but it's nice to have things labeled 'batch' and 'state' now that we have multiple buffers. Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need space and can't flush." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103101 Reviewed-by: Ian Romanick <[email protected]>
* i965: Don't grow batch/state buffer on every emit after an overflow.Kenneth Graunke2017-11-291-23/+19
| | | | | | | | | | | | | | | | | | | | Once we reach the intended size of the buffer (BATCH_SZ or STATE_SZ), we try and flush. If we're not allowed to flush, we resort to growing the buffer so that there's space for the data we need to emit. We accidentally got the threshold wrong. The first non-wrappable call beyond (e.g.) STATE_SZ would grow the buffer to floor(1.5 * STATE_SZ), The next call would see we were beyond STATE_SZ and think we needed to grow a second time - when the buffer was already large enough. We still want to flush when we hit STATE_SZ, but for growing, we should use the actual size of the buffer as the threshold. This way, we only grow when actually necessary. v2: Simplify the control flow (suggested by Jordan) Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need space and can't flush." Reviewed-by: Jordan Justen <[email protected]>
* i965: Preserve EXEC_OBJECT_CAPTURE when growing the BO.Kenneth Graunke2017-11-291-0/+3
| | | | | | | | | The original state buffer was marked with EXEC_OBJECT_CAPTURE. When growing it, we want to preserve that flag so we continue to capture it in GPU hang reports. Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need space and can't flush." Reviewed-by: Ian Romanick <[email protected]>
* i965: Use old_bo->align when growing batch/state buffer instead of 4096.Kenneth Graunke2017-11-291-1/+2
| | | | | | | | | | | | | | The intention here is make the new BO use the same alignment as the old BO. This isn't strictly necessary, but we would have to update the 'alignment' field in the validation list when swapping it out, and we don't bother today. The batch and state buffers use an alignment of 4096, so this should be equivalent - it's just clearer than cut and pasting a magic constant. Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need space and can't flush." Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Program the dynamic state heap size to MAX_STATE_SIZE.Kenneth Graunke2017-11-291-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | STATE_BASE_ADDRESS specifies a maximum size of the dynamic state section, beyond which data supposedly reads back as 0. On Gen8+, we were programming it to the size of the buffer. This worked fine until we started growing the state buffer in commit 2dfc119f22f25708. When the state buffer grows, the value in STATE_BASE_ADDRESS becomes too small, and our state beyond STATE_SZ bytes would read back as 0. To avoid having to update the value, we program it to MAX_STATE_SIZE. We used to program the upper bound to the maximum on older hardware anyway, so programming it too large isn't a big deal. Bogus SURFACE_STATE can easily lead to GPU hangs and misrendering. DiRT Rally was hitting the statebuffer growth path, and suffered from bad texture corruption and GPU hangs (usually around the same time). This patch fixes both issues. Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need space and can't flush." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103101 Tested-by: Jordan Justen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Support decoding INTERFACE_DESCRIPTOR_DATA with INTEL_DEBUG=batJordan Justen2017-11-211-0/+24
| | | | | | | | This will dump the INTERFACE_DESCRIPTOR_DATA along with the associated samplers & surfaces. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Scott D Phillips <[email protected]>
* i965: Upload invariant state once at the start of the batch on Gen4-5.Kenneth Graunke2017-11-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | We want to emit invariant state at the start of a render batch. In the past, this more or less happened: a new batch flagged BRW_NEW_CONTEXT (because we don't have hardware contexts), which triggered the brw_invariant_state atom. So, it would be emitted before any 3D drawing. (Technically, there might be some BLT commands in the batch because Gen4-5 have a single combined render/BLT ring, but that should be harmless). With the advent of BLORP, this broke. The first item in a batch might be a BLORP operation, which bypasses the normal draw upload path. So, we need to ensure invariant state happens first. To do that, we just upload it when creating a new batch. On Gen6+ we'd need to worry about whether it's a RENDER or BLT batch, but because we have a combined ring, this approach should work fine on Gen4-5. Seems to fix GPU hangs when playing hardware accelerated video with mpv -hwdec=vaapi on Ironlake. Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103529 Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Drop some reserved space remnants.Kenneth Graunke2017-11-151-3/+1
| | | | | | BATCH_RESERVED was deleted in commit 2c46a67b4138631217 (i965: Delete BATCH_RESERVED handling.) The reserved_space field is dead code, and the comments aren't useful these days.
* i965: Track the depth and render caches separatelyJason Ekstrand2017-11-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we just had one hash set for tracking depth and render caches called brw_context::render_cache. This is less than ideal because the depth and render caches are separate and we can't track moves between the depth and the render caches. This limitation led to some unnecessary flushing around the depth cache. There are cases (mostly with BLORP) where we can end up touching a depth or stencil buffer through the render cache. To guard against this, blorp would unconditionally do a render_cache_set_check_flush on it's destination which meant that if you did any rendering (including a BLORP operation) to a given surface and then used it as a blorp destination, you would end up flushing it out of the render cache before rendering into it. Things get worse when you dig into the depth/stencil state code for regular GL draw calls. Because we may end up rendering to a depth or stencil buffer via BLORP, we did a render_cache_set_check_flush on all depth and stencil buffers in brw_emit_depthbuffer to ensure that they got flushed out of the render cache prior to using them for depth or stencil testing. However, because we also need to track dirtiness for depth and stencil so that we can implement depth and stencil texturing correctly, we were adding all depth and stencil buffers to the render cache set in brw_postdraw_set_buffers_need_resolve. This meant that, if anything caused 3DSTATE_DEPTH_BUFFER to get re-emitted (currently _NEW_BUFFERS, BRW_NEW_BATCH, and BRW_NEW_BLORP), we would almost always do a full pipeline stall and render/depth cache flush. The root cause of both of these problems is that we can't tell the difference between the render and depth caches in our tracking. This commit splits our cache tracking into two sets, one for render and one for depth, and properly handles transitioning between the two. We still flush all the caches whenever anything needs to be flushed. The idea is that if we're going to take the hit of a flush and stall, we may as well flush everything in the hopes that we can avoid a flush by something else later. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: fix unused var warnings in release buildTimothy Arceri2017-10-251-12/+4
| | | | Reviewed-by: Jordan Justen <[email protected]>
* i965: Rename brw->no_batch_wrap to intel_batchbuffer::no_wrapKenneth Graunke2017-10-131-5/+5
| | | | | | This really makes more sense in the intel_batchbuffer struct. Reviewed-by: Chris Wilson <[email protected]>
* i965: Rename do_flush_locked to submit_batch().Kenneth Graunke2017-09-251-3/+4
| | | | | | | do_flush_locked isn't a great name - especially given that there's no locking going on in our code relating to execbuf. Reviewed-by: Chris Wilson <[email protected]>
* i965: Fix brw_finish_batch to grow the batchbuffer.Kenneth Graunke2017-09-211-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | brw_finish_batch emits commands needed at the end of every batch buffer, including any workarounds. In the past, we freed up some "reserved" batch space before calling it, so we would never have to flush during it. This was error prone and easy to screw up, so I deleted it a while back in favor of growing the batch. There were two problems: 1. We're in the middle of flushing, so brw->no_batch_wrap is guaranteed not to be set. Using BEGIN_BATCH() to emit commands would cause a recursive flush rather than growing the buffer as intended. 2. We already recorded the throttling batch before growing, which replaces brw->batch.bo with a different (larger) buffer. So growing would break throttling. These are easily remedied by shuffling some code around and whacking brw->no_batch_wrap in brw_finish_batch(). This also now includes the final workarounds in the batch usage statistics. Found by inspection. Fixes: 2c46a67b4138631217141f (i965: Delete BATCH_RESERVED handling.) Reviewed-by: Chris Wilson <[email protected]>
* i965: Move MI_BATCHBUFFER_END handling into brw_finish_batch().Kenneth Graunke2017-09-211-7/+7
| | | | | | This is, by definition, finishing the batch. Reviewed-by: Chris Wilson <[email protected]>
* i965: Fix batch map failure check in INTEL_DEBUG=bat handling.Kenneth Graunke2017-09-181-1/+1
| | | | | | | | | | I originally wrote the code to call the maps 'batch' and 'state', until I remembered that 'batch' is the intel_batchbuffer struct pointer. The NULL check was still using the wrong variable. Caught by Coverity. CID: 1418109
* i965: Warn for GTT fallbacks when mapping the batch/state buffers.Kenneth Graunke2017-09-181-2/+2
| | | | | | | | This shouldn't really happen in practice, but I hit it a couple of times when running a driver with a bad memory leak. We may as well hook up the warning, because if it ever triggers, we'll know something is wrong. Reviewed-by: Chris Wilson <[email protected]>
* i965: Plumb brw through to intel_batchbuffer_reset().Kenneth Graunke2017-09-181-8/+9
| | | | | | We'll want to pass this to brw_bo_map in a moment. Reviewed-by: Chris Wilson <[email protected]>
* i965: drop unused variablesEric Engestrom2017-09-151-1/+0
| | | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965: Print size of validation and relocation lists in INTEL_DEBUG=flushKenneth Graunke2017-09-141-3/+8
| | | | | | | | It's nice to have this information. While we're at it, tweak the formatting to try and vertically align numbers in the common case. Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Wilson <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 10:43:16 +0000