[Bug 105964] New: The bit2bit check failed on drm-tip for stream mbcode/mbstat/mvout AVC FEI encode

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=105964

            Bug ID: 105964
           Summary: The bit2bit check failed on drm-tip for stream
                    mbcode/mbstat/mvout AVC FEI encode
           Product: DRI
           Version: unspecified
          Hardware: Other
                OS: Linux (All)
            Status: NEW
          Severity: major
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: owen.zhang at intel.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 138721
  --> https://bugs.freedesktop.org/attachment.cgi?id=138721&action=edit
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 at chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen at 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 at 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".

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180410/218bd10d/attachment.html>