Bug 107938 - Failing test dEQP-GLES2.functional.clipping.triangle_vertex.clip_three.clip_neg_x_neg_z_and_pos_x_pos_z_and_neg_x_neg_y_pos_z
Summary: Failing test dEQP-GLES2.functional.clipping.triangle_vertex.clip_three.clip_n...
Status: RESOLVED WORKSFORME
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:
 
Reported: 2018-09-14 12:56 UTC by Gert Wollny
Modified: 2018-11-29 09:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
Test result of deqp-gles2 (5.92 KB, text/html)
2018-09-14 12:56 UTC, Gert Wollny 		Details
Diff between host api trace and qemu guest api trace (13.74 KB, text/plain)
2018-09-14 13:00 UTC, Gert Wollny 		Details
Diff between the state dumps right before the draw call (22.91 KB, text/plain)
2018-09-14 13:09 UTC, Gert Wollny 		Details
View All

Description Gert Wollny 2018-09-14 12:56:55 UTC 
Created attachment 141563 [details]
Test result of deqp-gles2

This test is failing for me on Intel Kabylake. 

One interesting fact: With the current virglrenderer git, when running the test through virgl in qemu the test actually passes. 

I've attached the processed output of the test.
Comment 1 Gert Wollny 2018-09-14 13:00:29 UTC 
Created attachment 141564 [details]
Diff between host api trace and qemu guest api trace

traces were shortened to only contain a few hundred lines before the glRead(n)Pixels that usually finalizes the tests.
Comment 2 Gert Wollny 2018-09-14 13:09:54 UTC 
Created attachment 141565 [details]
Diff between the state dumps right before the draw call
Comment 3 Mark Janes 2018-09-14 17:46:10 UTC 
This test has always been reliable in the i965 mesa ci.  Can you please provide:

 - dEQP version
 - kernel version
 - mesa version
 - libdrm version
 - dEQP configuration / invocation
Comment 4 Gert Wollny 2018-09-14 18:16:04 UTC 
Test system Ubuntu 18.04, all updated 

Mesa: 
  render string: Mesa DRI Intel (R)UHD Graphics 620 (Kabylake GT2) 

I've tested various versions: 
- mesa 18.0.5 (packaged version) 
- mesa 18.3.0-devel git-d6131916f26 

I also went back a few commits, because in April I tested it in qemu with virgl where it passed, and I though it was a regression, but, as pointed out above, in qemu it still passes and apparently always did. Unfortunately, I don't remember having tested this directly on the host at that time.

kernel: 4.15.0-34-generic
libdrm 2.4.91-2

dEQP: git-ff7282eb1b411d (It also failed with an earlier version)

Invocation:  ./deqp-gles2 -n <testname>
Comment 5 Mark Janes 2018-09-14 19:17:08 UTC 
That commit (ff7282eb1b411d) does not exist in our upstream dEQP:

https://android.googlesource.com/platform/external/deqp

We are using 9149a0bed.
Comment 6 Gert Wollny 2018-09-14 21:59:39 UTC 
I was referring to 

https://github.com/KhronosGroup/VK-GL-CTS/commit/ff7282eb1b411d2e85253d03337dc6e80be51f45

there 9149a0bed doesn't seem to exist ,..
Comment 7 Chema Casanova 2018-09-15 22:29:44 UTC 
I wasn't able to reproduce the failing test with the same VK-GL-CTS reported master commit neither with the CTS stable branch opengl-es-cts-3.2.5. I used both wayland and x11_egl as DEQP_TARGET

I used mesa master 14976817f4dbd0 and mesa-stable 18.1 with kernel 4.17.0-3-amd64

I used a similar hardware with an Intel(R) HD Graphics 630 (Kaby Lake GT2).

I tested also on SKL, BDW and HSW and I couldn't reproduce this test failure.
Comment 8 Mark Janes 2018-09-15 23:05:10 UTC 
I'm confused by the wording of your comment.  Are you saying that the test fails with VK-GL-CTS ff7282eb1b411d, but doesn't fail with:

  VK-GL-CTS master
Comment 9 Mark Janes 2018-09-15 23:08:42 UTC 
Sorry for the partially complete comment I just made.

I'm confused by the wording of your comment.  Are you saying that the test fails with VK-GL-CTS ff7282eb1b411d, but doesn't fail with:

  VK-GL-CTS master
  VK-GL-CTS opengl-es-cts-3.2.5.0

If so, it sounds like the CTS has a bug that may have already been fixed.  If so, please close as NOTOURBUG.

In the future, I would stick to AOSP master if you want to test newer dEQP.  We have fewer regressions from that repository than from the Khronos-maintained github repo.  I believe the khronos repo is downstream from AOSP.
Comment 10 Chema Casanova 2018-09-15 23:27:50 UTC 
(In reply to Mark Janes from comment #9)
> Sorry for the partially complete comment I just made.
> 
> I'm confused by the wording of your comment.  Are you saying that the test
> fails with VK-GL-CTS ff7282eb1b411d,

My wording was confusing. I couldn't replicate the fail reported by Gret on ff7282eb1b411d. That commit is github public master of VK-GL-CTS.

> but doesn't fail with:
> 
>   VK-GL-CTS master
>   VK-GL-CTS opengl-es-cts-3.2.5.0

> If so, it sounds like the CTS has a bug that may have already been fixed. 
> If so, please close as NOTOURBUG.

For me at this moment this bug is a WORKSFORME.

> In the future, I would stick to AOSP master if you want to test newer dEQP. 
> We have fewer regressions from that repository than from the
> Khronos-maintained github repo.  I believe the khronos repo is downstream
> from AOSP.

I agree on that.
Comment 11 Gert Wollny 2018-10-03 09:58:17 UTC 
Well, I now tried the dEQP AOSP version b57a8fe92b. 

I compiled dEQP with the default target and the x11_egl and in both cases  I still get the failure with mesa-18.0.5 and mesa-gitd631916f29. However, with that version of dEQP I also get the failure on r600/Barts and llvmpipe.

With the latter two drivers the test passes when using the github version (now updated to  57d5e6cdd5365b9).
Comment 12 Gert Wollny 2018-10-04 07:39:10 UTC 
Could you point out how this was fixed? Many thanks, Gert
Comment 13 Mark Janes 2018-10-04 17:56:14 UTC 
Sorry, I misread your comment, and thought you meant that i965 was working on master.

We also build deqp with:

 cmake -GNinja  -DDEQP_TARGET=x11_egl

Our results for this test are now hosted in a public database, and you can see for yourself that it has always passed:

 https://mesa-ci.01.org/mesa_master/test/45736df9caccf27df39a1239953c2c80/history

Can anyone else reproduce this failure?

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.