Bug 107675 - [Regression] [bisected] [GLES 3.1 CTS] [GL 4.4 CTS] [BDW] *.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_MaxPatchVertices_Position_PointSize
Summary: [Regression] [bisected] [GLES 3.1 CTS] [GL 4.4 CTS] [BDW] *.tessellation_shad...
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 102590
  Show dependency treegraph
 
Reported: 2018-08-24 13:16 UTC by Andrés Gómez García
Modified: 2019-08-08 14:22 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrés Gómez García 2018-08-24 13:16:16 UTC
This is not an usual regression report.

It seems that for quite some time the *.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_MaxPatchVertices_Position_PointSize tests have been flaky in BDW. Possibly in other gens too.

The thing is that the fail rate was ~0.1% and it was very difficult to encounter.

In the last 3 weeks I've noticed the flakiness of these tests because the fail rate has increased to ~1.5%.

What I'm observing is that, after:

--

commit 4434591bf56a6b0c193ef209ea9d7b9e3c95a522
Author: Jason Ekstrand <jason.ekstrand@intel.com>
Date:   Tue Jul 31 06:16:34 2018 -0700

    intel/nir: Call nir_lower_io_to_scalar_early
    
    Shader-db results on Kaby Lake:
    
        total instructions in shared programs: 15166953 -> 15073611 (-0.62%)
        instructions in affected programs: 2390284 -> 2296942 (-3.91%)
        helped: 16469
        HURT: 505
    
        total loops in shared programs: 4954 -> 4951 (-0.06%)
        loops in affected programs: 3 -> 0
        helped: 3
        HURT: 0
    
    Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

--

The fail rate increased to ~1%.

And, just after the immediate commit:

--

commit 7f75cf2a9408b9af562e033ef6c1d1fd15141421
Author: Jason Ekstrand <jason.ekstrand@intel.com>
Date:   Sat Oct 28 09:05:01 2017 -0700

    nir/lower_indirect: Bail early if modes == 0
    
    There's no point in walking the program if we're never going to actually
    lower anything.
    
    Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

--

The fail rate increased to ~1.5%.

Please, take these observations with a grain of salt. I've done a very limited amount of test runs and the fail rate is so small that it is difficult to state for sure, but I believe the bisection is correct.

--

I noticed KHR-GL46 failure with the config-gl46-master-cfg-3-run-0-width-64-height-64-seed-1 and config-gl46-master-cfg-4-run-0-width-64-height-64-seed-1 CTS profiles. Hence, these would be examples of execution, but it doesn't mean that the failure is limited to these profiles:

--

$ ./glcts --deqp-
case=KHR-GL46.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_MaxPatchVertices_Position_PointSize --deqp-screen-rotation=unspecified --deqp-surface-width=64 --deqp-surface-height=64 --deqp-watchdog=disable --deqp-base-seed=1 --deqp-surface-type=window --deqp-gl-config-id=3 --deqp-gl-context-type=egl

--

$ ./glcts --deqp-
case=KHR-GL46.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_MaxPatchVertices_Position_PointSize --deqp-screen-rotation=unspecified --deqp-surface-width=64 --deqp-surface-height=64 --deqp-watchdog=disable --deqp-base-seed=1 --deqp-surface-type=window --deqp-gl-config-id=4 --deqp-gl-context-type=egl

--

I noticed KHR-GLES31 failure with the config-gles31-khr-master-cfg-5-run-2-width-64-height-64-seed-1 CTS profile. Hence, this would be an example of execution, but it doesn't mean that the failure is limited to this profile:

--

./glcts --deqp-
case=KHR-GLES31.core.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_MaxPatchVertices_Position_PointSize --deqp-screen-rotation=unspecified --deqp-surface-width=64 --deqp-surface-height=64 --deqp-watchdog=disable --deqp-base-seed=1 --deqp-surface-type=window --deqp-gl-config-id=5 --deqp-gl-context-type=egl

--

I noticed KHR-GLES32 failure with the config-gles31-khr-master-cfg-5-run-2-width-64-height-64-seed-1 CTS profile. Hence, this would be an example of execution, but it doesn't mean that the failure is limited to this profile:

--

./glcts --deqp-
case=KHR-GLES32.core.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_MaxPatchVertices_Position_PointSize --deqp-screen-rotation=unspecified --deqp-surface-width=64 --deqp-surface-height=64 --deqp-watchdog=disable --deqp-base-seed=1 --deqp-surface-type=window --deqp-gl-config-id=4 --deqp-gl-context-type=egl
Comment 1 Andrés Gómez García 2018-08-24 13:27:36 UTC
Maybe related to bug 103837 ?
Comment 2 Mark Janes 2018-08-24 14:03:39 UTC
I can confirm that this test is flaky on BDW in Mesa CI, and it was disabled on that platform a couple of weeks ago.
Comment 3 Andrés Gómez García 2018-08-28 21:52:30 UTC
FTR, OpenGL tests were run against the "opengl-cts-4.6.0" branch and the x11_egl target:
https://github.com/KhronosGroup/VK-GL-CTS/tree/opengl-cts-4.6.0

While OpenGLES tests were run against the "opengl-es-cts-3.2.5" branch and the wayland target:
https://github.com/KhronosGroup/VK-GL-CTS/tree/opengl-es-cts-3.2.5


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.