Bug 107675

Summary: [Regression] [bisected] [GLES 3.1 CTS] [GL 4.4 CTS] [BDW] *.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_MaxPatchVertices_Position_PointSize
Product: Mesa Reporter: Andrés Gómez García <agomez>
Component: Drivers/DRI/i965Assignee: Intel 3D Bugs Mailing List <intel-3d-bugs>
Status: RESOLVED MOVED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: agoldmints, agomez, jason, jmcasanova, kenneth, t_arceri
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 102590    

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
Comment 4 GitLab Migration User 2019-09-25 19:13:21 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1750.

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.