[Bug 109357] [SKL] [REGRESSION] [BISECTED] [OpenGL CTS] Many flaky tests after adding workarounds for object preemption in gen9

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jan 14 17:04:36 UTC 2019


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

            Bug ID: 109357
           Summary: [SKL] [REGRESSION] [BISECTED] [OpenGL CTS] Many flaky
                    tests after adding workarounds for object preemption
                    in gen9
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: intel-3d-bugs at lists.freedesktop.org
          Reporter: agomez at igalia.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org
                CC: rafael.antognolli at intel.com

After:

--

commit 5c454661c66fa2624cf4bba1071175070724869a
Author: Rafael Antognolli <rafael.antognolli at intel.com>
Date:   Mon Oct 29 10:19:54 2018 -0700

    i965/gen9: Add workarounds for object preemption.

    Gen9 hardware requires some workarounds to disable preemption depending
    on the type of primitive being emitted.

    We implement this by adding a function that checks the primitive type
    and number of instances right before the 3DPRIMITIVE.

    For now, we just ignore blorp.  The only primitive it emits is
    3DPRIM_RECTLIST, and since it's not listed in the workarounds, we can
    safely leave preemption enabled when it happens. Or it will be disabled
    by a previous 3DPRIMITIVE, which should be fine too.

    v3:
     - Apply missing workarounds for instanced rendering and line loop (Ken)
     - Move workaround code to brw_draw_single_prim()

    Signed-off-by: Rafael Antognolli <rafael.antognolli at intel.com>
    Cc: Kenneth Graunke <kenneth at whitecape.org>
    Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

--

(At least) The following tests are failing when running the cts-runner for gl45
in SKL with the x11_egl target:

--

KHR-GL45.enhanced_layouts.xfb_global_buffer
KHR-GL45.geometry_shader.rendering.rendering.lines_input_points_output_line_strip_drawcall
KHR-GL45.gpu_shader5.uniform_blocks_array_indexing
KHR-GL45.gpu_shader_fp64.builtin.*
KHR-GL45.sepshaderobjs.InterfacePrecisionMatchingInt
KHR-GL45.shader_storage_buffer_object.basic-operations-case2-vs
KHR-GL45.shader_subroutine.control_flow_and_returned_subroutine_values_used_as_subroutine_input
KHR-GL45.shader_subroutine.eight_subroutines_four_uniforms
KHR-GL45.shader_subroutine.four_subroutines_with_two_uniforms
KHR-GL45.shader_subroutine.subroutines_with_separate_shader_objects
KHR-GL45.shader_subroutine.two_subroutines_single_subroutine_uniform
KHR-GL45.shading_language_420pack.binding_uniform_single_block
KHR-GL45.shading_language_420pack.implicit_conversions
KHR-GL45.texture_view.view_sampling

--

The hardware is an Intel NUC:

--

$ glxinfo | grep Skylake
    Device: Mesa DRI Intel(R) Iris Graphics 540 (Skylake GT3e)  (0x1926)
OpenGL renderer string: Mesa DRI Intel(R) Iris Graphics 540 (Skylake GT3e) 

--

Notice that I *cannot* reproduce this regression with KBL.

Notice also that I cannot reproduce this regression running the same tests
individually applying the reportedly affected profiles: this only shows up when
running with the cts-runner.

Notice that failing tests tend to vary, but the presence of many failures in
KHR-GL45.gpu_shader_fp64.builtin.* is constant.

This is a quick command to be able to replay the CTS run with the same codebase
with docker:

--

$ RESULTS_DIRECTORY=<my_results_directory_path>
$ docker run --privileged --rm -t -v "$RESULTS_DIRECTORY":/results:Z -e
DISPLAY=unix:0.0 -v /tmp/.X11-unix:/tmp/.X11-unix
registry.gitlab.com/igalia/graphics/vk-gl-cts:wip-agomez-gen9-workarounds-for-object-preemption_wip-agomez-gen9-workarounds-for-object-preemption
/bin/bash -c "cd ~/vk-gl-cts/build/external/openglcts/modules; TIMESTAMP=`date
+%Y%m%d%H%M%S`; RCR_CTS_RUNNER_TYPE="gl45"; mkdir -p
/results/cts-runner/\$RCR_CTS_RUNNER_TYPE-\$TIMESTAMP; ./cts-runner
--type=\$RCR_CTS_RUNNER_TYPE
--logdir=/results/\$RCR_CTS_RUNNER_TYPE-\$TIMESTAMP"

--

The local versions are:

--

$ uname -a
Linux panix 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
$ cat /var/log/Xorg.0.log
[  2171.328]
X.Org X Server 1.16.4
Release Date: 2014-12-20
[  2171.328] X Protocol Version 11, Revision 0
[  2171.328] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[  2171.328] Current Operating System: Linux nucbot1 3.16.0-4-amd64 #1 SMP
Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64                                     

...

[  2171.328] Build Date: 11 February 2015  12:32:02AM
[  2171.328] xorg-server 2:1.16.4-1 (http://www.debian.org/support)

...

[  2171.332] (II) LoadModule: "intel"
[  2171.332] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[  2171.332] (II) Module intel: vendor="X.Org Foundation"
[  2171.332]    compiled for 1.15.99.904, module version = 2.21.15
[  2171.332]    Module class: X.Org Video Driver
[  2171.332]    ABI class: X.Org Video Driver, version 18.0

...

--

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20190114/1193e215/attachment-0001.html>


More information about the intel-3d-bugs mailing list