Created attachment 138721 [details] reproducer_package When Running AVC FEI encode workloads, we find the output data:mbcode/mbstat/mvout are different after each test for same input stream. the expected result: mbcode/mbstat/mvout are same for each test. this issue only reproduce on Broadwell hardware, hasn't found on SKL. *the Video Device: Iris Graphics 6100(0x162b) ----------------- this issue is a regression, we had bisect the issue patch: https://patchwork.freedesktop.org/patch/162046/ [CI,04/10] drm/i915: Eliminate lots of iterations over the execobjects array The major scaling bottleneck in execbuffer is the processing of the execobjects. Creating an auxiliary list is inefficient when compared to using the execobject array we already have allocated. Reservation is then split into phases. As we lookup up the VMA, we try and bind it back into active location. Only if that fails, do we add it to the unbound list for phase 2. In phase 2, we try and add all those objects that could not fit into their previous location, with fallback to retrying all objects and evicting the VM in case of severe fragmentation. (This is the same as before, except that phase 1 is now done inline with looking up the VMA to avoid an iteration over the execobject array. In the ideal case, we eliminate the separate reservation phase). During the reservation phase, we only evict from the VM between passes (rather than currently as we try to fit every new VMA). In testing with Unreal Engine's Atlantis demo which stresses the eviction logic on gen7 class hardware, this speed up the framerate by a factor of 2. The second loop amalgamation is between move_to_gpu and move_to_active. As we always submit the request, even if incomplete, we can use the current request to track active VMA as we perform the flushes and synchronisation required. The next big advancement is to avoid copying back to the user any execobjects and relocations that are not changed. v2: Add a Theory of Operation spiel. v3: Fall back to slow relocations in preparation for flushing userptrs. v4: Document struct members, factor out eb_validate_vma(), add a few more comments to explain some magic and hide other magic behind macros. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem_evict.c | 92 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2042 +++++++++++++---------- drivers/gpu/drm/i915/i915_vma.c | 2 +- drivers/gpu/drm/i915/i915_vma.h | 1 + drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 4 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 16 +- 7 files changed, 1241 insertions(+), 918 deletions(-) ----------------- this issue can be reproduced in drm-tip. the last commit is: commit 617cdf0bd4fd2cb0dcc64ddf07fbb56572ba800a Author: Eric Anholt <eric@anholt.net> Date: Mon Apr 9 12:59:13 2018 -0700 drm-tip: 2018y-04m-09d-19h-55m-54s UTC integration manifest the reproduce steps: 1) Build this stack: https://software.intel.com/en-us/articles/build-and-debug-open-source-media-stack 2) ./repr.sh the result will show the "FAILED".
Created attachment 138722 [details] sample_fei binary
Thanks for your detailed bug report. I assigned the bug to Chris since it has been bisected to his patch.
Check your userspace code very carefully, for it is buggy ;)
The usual explanation here is either a missing write hazard, an invalid relocation, or reusing a stale relocation value before updating it later in the batch.
Created attachment 138724 [details] input stream
thanks for your reply, Is it any difference for BDW and SKL? since we can't reproduce this issue on SKL using same userspace libnaries. (In reply to Chris Wilson from comment #4) > The usual explanation here is either a missing write hazard, an invalid > relocation, or reusing a stale relocation value before updating it later in > the batch.
Chris, is this valid bug?
In your code you make the assumption that offset 0 is empty; either leaving an address pointing to 0 or by omission of a relocation/patch. If it is the same bug as last time it is because you are trying to use a relative offset of 0 before you specify the base addresses.
Closing, please re-open if occurs again.
Hi, I'm sorry for this, i need re-open this issue, due to i checked the userspace code, we haven't specified the offset 0. but i have the following one experient: i changed the following code in libdrm: bo_gem->relocs[bo_gem->reloc_count].presumed_offset = -1; I think all the offsets from KMD are invalided, all the BOs need to do the reloc in KMD, Does this understanding right? thanks a lot.
Jani, Chris, any help here?
Owen, what was reason to resolve this now?
in fact, we haven't solved this issue currently, but as Chris mentioned, the userspace need to deal with the bo which relocate to address 0. we are checking the UMD code again. so i set this status to close. thanks. (In reply to Jani Saarinen from comment #12) > Owen, what was reason to resolve this now?
OK, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.