- 17 Aug, 2022 2 commits
-
-
Matt Roper authored
Some additional MMIO tuning settings have appeared in the bspec's performance tuning guide section. One of the tuning settings here is also documented as formal workaround Wa_22012654132 for some steppings of DG2. However the tuning setting applies to all DG2 variants and steppings, making it a superset of the workaround. v2: - Move DRAW_WATERMARK to engine workaround section. It only moves into the engine context on future platforms. (Lucas) - CHICKEN_RASTER_2 needs to be handled as a masked register. (Lucas) Bspec: 68331 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220816210601.2041572-2-matthew.d.roper@intel.com
-
Matt Roper authored
The bspec performance tuning section gives recommended settings that the driver should program for various MMIO registers. Although these settings aren't "workarounds" we use the workaround infrastructure to do this programming to make sure it is handled at the appropriate places and doesn't conflict with any real workarounds. Since more of these are starting to show up on recent platforms, it's a good time to create a dedicated function to hold them so that there's less ambiguity about how/where to implement new ones. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 09 Aug, 2022 2 commits
-
-
Matthew Auld authored
Crucible + recent Mesa seems to sometimes hit: GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER) And it looks like we can also trigger this with gem_lmem_swapping, if we modify the test to use slightly larger object sizes. Looking closer it looks like we have the following issues in migrate_copy(): - We are using plain integer in various places, which we can easily overflow with a large object. - We pass the entire object size (when the src is lmem) into emit_pte() and then try to copy it, which doesn't work, since we only have a few fixed sized windows in which to map the pages and perform the copy. With an object > 8M we therefore aren't properly copying the pages. And then with an object > 64M we trigger the GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER). So it looks like our copy handling for any object > 8M (which is our CHUNK_SZ) is currently broken on DG2. Fixes: da0595ae ("drm/i915/migrate: Evict and restore the flatccs capable lmem obj") Testcase: igt@gem_lmem_swapping Signed-off-by:Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ramalingam C<ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220805132240.442747-2-matthew.auld@intel.com
-
Matthew Auld authored
We only ever need to emit one ccs block copy command. Signed-off-by:
-
- 08 Aug, 2022 1 commit
-
-
Mauro Carvalho Chehab authored
WRITE_ONCE() should happen at the original var, not on a local copy of it. Cc: stable@vger.kernel.org Fixes: 5d36acb7 ("drm/i915/gt: Batch TLB invalidations") Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> [added cc-stable while merging it] Link: https://patchwork.freedesktop.org/patch/msgid/f9550e6bacea10131ff40dd8981b69eb9251cdcd.1659598090.git.mchehab@kernel.org
-
- 03 Aug, 2022 1 commit
-
-
Chris Wilson authored
The obj->base.resv may be shared across many objects, some of which may still be live and locked, preventing objects from being freed indefintely. We could individualise the lock during the free, or rely on a freed object having no contention and being able to immediately free the pages it owns. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6469 Fixes: be7612fd ("drm/i915: Require object lock when freeing pages during destruction") Fixes: 6cb12fbd ("drm/i915: Use trylock instead of blocking lock for __i915_gem_free_objects.") Cc: <stable@vger.kernel.org> # v5.17+ Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Tested-by:
Nirmoy Das <nirmoy.das@intel.com> Acked-by:
-
- 02 Aug, 2022 2 commits
-
-
Harish Chegondi authored
Bspec: 46052 Reviewed-by:
Harish Chegondi <harish.chegondi@intel.com> Signed-off-by:
-
John Harrison authored
New release of GuC with a bunch of fixes specific to DG2. Some of these require follow up i915 changes to enable. Note also that it is not necessary to maintain backwards compatibility with 70.1.2 for DG2 because DG2 is still under force probe protection. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220728230722.2749701-2-John.C.Harrison@Intel.com
-
- 01 Aug, 2022 1 commit
-
-
Daniele Ceraolo Spurio authored
The GuC FW applies the parent context policy to all the children, so individual updates to the children are not supported and we should not send them. Note that sending the message did not have any functional consequences, because the GuC just drops it and logs an error; since we were trying to set the child policy to match the parent anyway the message being dropped was not a problem. Signed-off-by:
-
- 29 Jul, 2022 6 commits
-
-
John Harrison authored
When the KMD sends a CLIENT_RESET request to GuC (as part of the suspend sequence), GuC will mark the CTB buffer as 'UNUSED'. If the KMD then checked the CTB queue, it would see a non-zero status value and report the buffer as corrupted. Technically, no G2H messages should be received once the CLIENT_RESET has been sent. However, if a context was outstanding on an engine then it would get reset and a reset notification would be sent. So, don't actually treat UNUSED as a catastrophic error. Just flag it up as unexpected and keep going. Signed-off-by:
-
Matthew Brost authored
The GuC needs a copy of a golden context for implementing watchdog resets (aka media resets). This context is larger on newer platforms. So adjust the size being allocated/copied accordingly. Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
John Harrison authored
It is no longer guaranteed that there will always be an RCS engine. So, use the helper function for finding the first available engine that can be used for general purpose selftets. Signed-off-by:
-
Rahul Kumar Singh authored
Add a test to check that the hangcheck will recover from a submission hang in the GuC. Signed-off-by:
Rahul Kumar Singh <rahul.kumar.singh@intel.com> Signed-off-by:
-
Matthew Brost authored
Having semaphores results in different behavior when a dependent request is cancelled. In the case of semaphores the request could be on the HW and complete successfully while without the request is held in the driver and the error from the dependent request is propagated. Fix live_preempt_cancel to take this behavior into account. Also update live_preempt_cancel to use new function intel_context_ban rather than intel_context_set_banned. Signed-off-by:
-
Michał Winiarski authored
In GuC submission mode, there is an option to use auto-switch out semaphores and have GuC auto-switch in a waiting context. This requires routing the semaphore interrupt to GuC. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
- 28 Jul, 2022 10 commits
-
-
Zhanjun Dong authored
We are seeing error message of "No response for request". Some cases happened while waiting for response and reset/suspend action was triggered. In this case, no response is not an error, active requests will be cancelled. This patch will handle this condition and change the error message into debug message. Signed-off-by:
Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
TLB cache invalidation can happen on two different situations: 1. synchronously, at __vma_put_pages(); 2. asynchronously. On the first case, TLB cache invalidation happens inside __vma_put_pages(). So, no need to do it later on. However, on the second case, the pages will keep in memory until __i915_vma_evict() is called. So, we need to store the TLB data at struct i915_vma_resource, in order to do a TLB cache invalidation before allowing userspace to re-use the same memory. So, i915_vma_resource_unbind() has gained a new parameter in order to store the TLB data at the second case. Document it. Reviewed-by:
-
Chris Wilson authored
Invalidate TLB in batches, in order to reduce performance regressions. Currently, every caller performs a full barrier around a TLB invalidation, ignoring all other invalidations that may have already removed their PTEs from the cache. As this is a synchronous operation and can be quite slow, we cause multiple threads to contend on the TLB invalidate mutex blocking userspace. We only need to invalidate the TLB once after replacing our PTE to ensure that there is no possible continued access to the physical address before releasing our pages. By tracking a seqno for each full TLB invalidate we can quickly determine if one has been performed since rewriting the PTE, and only if necessary trigger one for ourselves. That helps to reduce the performance regression introduced by TLB invalidate logic. [mchehab: rebased to not require moving the code to a separate file] Cc: stable@vger.kernel.org Fixes: 7938d615 ("drm/i915: Flush TLBs before releasing backing store") Suggested-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Chris Wilson <chris.p.wilson@intel.com> Cc: Fei Yang <fei.yang@intel.com> Signed-off-by:
-
Chris Wilson authored
Skip all further TLB invalidations once the device is wedged and had been reset, as, on such cases, it can no longer process instructions on the GPU and the user no longer has access to the TLB's in each engine. So, an attempt to do a TLB cache invalidation will produce a timeout. That helps to reduce the performance regression introduced by TLB invalidate logic. Cc: stable@vger.kernel.org Fixes: 7938d615 ("drm/i915: Flush TLBs before releasing backing store") Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Ensure that the TLB of the OA unit is also invalidated on gen12 HW, as just invalidating the TLB of an engine is not enough. Cc: stable@vger.kernel.org Fixes: 7938d615 ("drm/i915: Flush TLBs before releasing backing store") Signed-off-by:
-
Mauro Carvalho Chehab authored
Add a kernel-doc markup to document this new macro. Reviewed-by:
-
Chris Wilson authored
Check if the device is powered down prior to any engine activity, as, on such cases, all the TLBs were already invalidated, so an explicit TLB invalidation is not needed, thus reducing the performance regression impact due to it. This becomes more significant with GuC, as it can only do so when the connection to the GuC is awake. Cc: stable@vger.kernel.org Fixes: 7938d615 ("drm/i915: Flush TLBs before releasing backing store") Signed-off-by:
-
Matthew Auld authored
The kernel only manages the ccs state with lmem-only objects, however the kernel should still take care not to leak the CCS state from the previous user. Fixes: 48760ffe ("drm/i915/gt: Clear compress metadata for Flat-ccs objects") Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220727164346.282407-1-matthew.auld@intel.com
-
Nirmoy Das authored
PCI bar resize only works with 64 bit BAR so disable this on 32-bit machine and resolve below compilation error: drivers/gpu/drm/i915/gt/intel_region_lmem.c:94:23: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] root_res->start > 0x100000000ull) Fixes: a91d1a17 ("drm/i915: Add support for LMEM PCIe resizable bar") Reported-by:Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
-
Chris Wilson authored
We report object allocation failures to userspace with ENOMEM, yet we still show the memory warning after failing to shrink device allocated pages. While this warning is similar to other system page allocation failures, it is superfluous to the ENOMEM provided directly to userspace. v2: Add NOWARN in few more places from where we might return ENOMEM to userspace. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4936Signed-off-by:
-
- 21 Jul, 2022 2 commits
-
-
Jason Wang authored
Fix the double `wait' typo in comment. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
-
Jason Wang authored
The semicolon after the `}' is unneeded. Signed-off-by:
-
- 20 Jul, 2022 1 commit
-
-
John Harrison authored
A bunch of code was copy/pasted using pr_err as the default way to report errors. However, drm_err is significantly more useful in identifying where the error came from. So update the code to use that instead. Signed-off-by:
-
- 19 Jul, 2022 3 commits
-
-
Daniele Ceraolo Spurio authored
This patch re-introduces support for GuC v69 in parallel to v70. As this is a quick fix, v69 has been re-introduced as the single "fallback" guc version in case v70 is not available on disk and only for platforms that are out of force_probe and require the GuC by default. All v69 specific code has been labeled as such for easy identification, and the same was done for all v70 functions for which there is a separate v69 version, to avoid accidentally calling the wrong version via the unlabeled name. When the fallback mode kicks in, a drm_notice message is printed in dmesg to inform the user of the required update. The existing logging of the fetch function has also been updated so that we no longer complain immediately if we can't find a fw and we only throw an error if the fetch of both the base and fallback blobs fails. The plan is to follow this up with a more complex rework to allow for multiple different GuC versions to be supported at the same time. v2: reduce the fallback to platform that require it, switch to firmware_request_nowarn(), improve logs. Fixes: 2584b354 ("drm/i915/guc: Update to GuC version 70.1.1") Link: https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.htmlSigned-off-by:
-
Ashutosh Dixit authored
Add the following sysfs files to gt/gtN/.defaults/: * rps_min_freq_mhz * rps_max_freq_mhz v2: Correct gt/gtN/.defaults/* file names in commit message v3: Remove rps_boost_freq_mhz since it is not consumed by userspace Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
Ashutosh Dixit authored
Create a gt/gtN/.defaults/ directory (similar to engine/<engine-name>/.defaults/) to expose default parameter values for each gt in sysfs. This allows userspace to restore default parameter values after they have changed. The empty 'struct gt_defaults' will be populated by subsequent patches. v2: Changed 'struct intel_rps_defaults rps_defaults' to 'struct gt_defaults defaults' (Andi) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 15 Jul, 2022 1 commit
-
-
Chris Wilson authored
When resuming after hibernate sometimes we see hangs in unrelated kernel subsystems. These hangs often result in the following i915 trace: i915 0000:00:02.0: [drm] *ERROR* \ intel_gt_reset_global timed out, cancelling all in-flight rendering implying our reset task has been starved by the hanging kernel subsystem, causing us to inappropiately declare the system as wedged beyond recovery. The trace would be caused by our synchronize_srcu_expedited() taking more than the allowed 5s due to the unrelated kernel hang. But we neither need to perform that synchronisation inside the reset watchdog, nor do we need such a short timeout before declaring the device as unrecoverable. v2: Restore watchdog timeout to the previous 5 seconds (Ashutosh) Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3575Signed-off-by:
-
- 13 Jul, 2022 4 commits
-
-
Priyanka Dandamudi authored
For testing purposes, support forcing the lmem_bar_size through a new modparam. In CI we only have a limited number of configurations for DG2, but we still need to be reasonably sure we get a usable device (also verifying we report the correct values for things like probed_cpu_visible_size etc) with all the potential lmem_bar sizes that we might expect see in the wild. v2: Update commit message and a minor modification.(Matt) v3: Optimised lmem bar size code and modified code to resize bar maximum upto lmem_size instead of maximum supported size.(Nirmoy) v4: Optimised lmem bar size code.(Nirmoy) Signed-off-by:
Priyanka Dandamudi <priyanka.dandamudi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
-
Akeem G Abodunrin authored
Add support for the local memory PICe resizable bar, so that local memory can be resized to the maximum size supported by the device, and mapped correctly to the PCIe memory bar. It is usual that GPU devices expose only 256MB BARs primarily to be compatible with 32-bit systems. So, those devices cannot claim larger memory BAR windows size due to the system BIOS limitation. With this change, it would be possible to reprogram the windows of the bridge directly above the requesting device on the same BAR type. v2:Moved code to gt/intel_region_lmem.c and used only single underscore for function names.(Jani) v3: Optimised code. Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Signed-off-by:
-
Matt Roper authored
Accidental use of a "SLICE" macro where a "SUBSLICE" macro was intended causes the group ID for steering to be calculated incorrectly on pre-Xe_HP platforms. Fixes: 9a92732f ("drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr") Signed-off-by:
-
Matthew Auld authored
Since segment_pages is no longer a compile time constant, it looks the DIV_ROUND_UP(node->size, segment_pages) breaks the 32b build. Simplest is just to use the ULL variant, but really we should need not need more than u32 for the page alignment (also we are limited by that due to the sg->length type), so also make it all u32. Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: bc99f120 ("drm/i915/ttm: fix sg_table construction") Signed-off-by:
-
- 12 Jul, 2022 4 commits
-
-
Andrzej Hajda authored
On some machines hole_end can be small enough to cause subtraction overflow. On the other side (addr + 2 * min_alignment) can overflow in case of mock tests. This patch should handle both cases. Fixes: e1c5f754 ("drm/i915: Avoid overflow in computing pot_hole loop termination") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3674Signed-off-by:
-
Chris Wilson authored
One impact of commit 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv workaround") is that it stores many, many more fences. Whereas adding an exclusive fence used to remove the shared fence list, that list is now preserved and the write fences included into the list. Not just a single write fence, but now a write/read fence per context. That causes us to have to track more fences than before (albeit half of those are redundant), and we trigger more interrupts for multi-engine workloads. As part of reducing the impact from handling more signaling, we observe we only need to kick the signal worker after adding a fence iff we have good cause to believe that there is work to be done in processing the fence i.e. we either need to enable the interrupt or the request is already complete but we don't know if we saw the interrupt and so need to check signaling. References: 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv workaround") Signed-off-by:
Karolina Drobnik <karolina.drobnik@intel.com> Reviewed-by:
-
Chris Wilson authored
In monitoring a transcode pipeline that is latency sensitive (it waits between submitting frames, and each frame requires work on rcs/vcs/vecs engines), it is found that it took longer than a single jiffy for it to sustain its workload. Allowing an extra jiffy headroom for the userspace prevents us from prematurely parking and having to exit powersaving immediately. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/6284Signed-off-by:
-
Chris Wilson authored
We employ a "waitboost" heuristic to detect when userspace is stalled waiting for results from earlier execution. Under latency sensitive work mixed between the gpu/cpu, the GPU is typically under-utilised and so RPS sees that low utilisation as a reason to downclock the frequency, causing longer stalls and lower throughput. The user left waiting for the results is not impressed. On applying commit 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv workaround") it was observed that deinterlacing h264 on Haswell performance dropped by 2-5x. The reason being that the natural workload was not intense enough to trigger RPS (using HW evaluation intervals) to upclock, and so it was depending on waitboosting for the throughput. Commit 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv workaround") changes the composition of dma-resv from keeping a single write fence + multiple read fences, to a single array of multiple write and read fences (a maximum of one pair of write/read fences per context). The iteration order was also changed implicitly from all-read fences then the single write fence, to a mix of write fences followed by read fences. It is that ordering change that belied the fragility of waitboosting. Currently, a waitboost is inspected at the point of waiting on an outstanding fence. If the GPU is backlogged such that we haven't yet stated the request we need to wait on, we force the GPU to upclock until the completion of that request. By changing the order in which we waited upon requests, we ended up waiting on those requests in sequence and as such we saw that each request was already started and so not a suitable candidate for waitboosting. Instead of asking whether to boost each fence in turn, we can look at whether boosting is required for the dma-resv ensemble prior to waiting on any fence, making the heuristic more robust to the order in which fences are stored in the dma-resv. Reported-by:
Thomas Voegtle <tv@lio96.de> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6284 Fixes: 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv workaround") Signed-off-by:
-
