Bug 100010 - [SNB] Blue noise in glBenchmark
Summary: [SNB] Blue noise in glBenchmark
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 13.0
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: 2017-02-28 16:47 UTC by Mike Gorchak
Modified: 2018-04-23 06:56 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Look at hero back - there a lot of blue/violet dots and lines. (7.91 MB, image/bmp)
2017-02-28 16:47 UTC, Mike Gorchak
Details
look at statue butt - there a lot of blue/violet dots and lines. (7.91 MB, image/bmp)
2017-02-28 16:47 UTC, Mike Gorchak
Details
High polygon count tesselation test (27.23 KB, application/gzip)
2017-02-28 18:12 UTC, Mike Gorchak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Gorchak 2017-02-28 16:47:06 UTC
Created attachment 129985 [details]
Look at hero back - there a lot of blue/violet dots and lines.

I used two Mesa3D versions: 12.0.6 and 13.0.5 on Intel SandyBridge (Gen6) reference motherboard.

Also I tried different Intel kernel DRM drivers for i915 for last two years (no big difference).

Some simple applications like gears, tunnel works perfect, even some complex one works perfect too.

Problems start when I run glBenchmark 2.5.1 and glBenchmark 3.0 tests. glBenchmark 3.0 doesn't work at all, immediately locking up GPU, glBenchmark 2.5.1 can work up-to 30 minutes with a lot of rendering artifacts and then finally lock up GPU too.

Kernel DRM trying to resume GPU according to messages:

drm/i915: Resetting chip after gpu hang
[drm:80d0e4es] *ERROR* Timed out waiting for the gpu reset to complete

Sometimes successfully, sometimes not. If reset was successful, usually GPU became locked up within very short period again.

Additionally Mesa 13.0.5 can't compile shaders shipped with glBenchmark 2.5.1 test, it complains with following error (never happens on 12.0.6):

GLBLog: error: declarations for uniform `fragmentColorVP` have mismatching precision qualifiers
GLBLog: glGetError 502

Two attachments:

glbenchmark251-12.0.6-sandy2.bmp - look at hero back - there a lot of blue/violet dots and lines.

glbenchmark251-12.0.6-sandy3.bmp - look at statue butt - there the same blue and violet dots and lines.
Comment 1 Mike Gorchak 2017-02-28 16:47:46 UTC
Created attachment 129986 [details]
look at statue butt - there a lot of blue/violet dots and lines.
Comment 2 Mike Gorchak 2017-02-28 18:12:30 UTC
Created attachment 129987 [details]
High polygon count tesselation test

Similar issues could be reproduced with following small test (I hope with it there much less efforts required to debug Mesa3D rather than using glBenchmark).

This test is designed to be run under Screen/QNX environment, so you have to modify gles1-teapot.c module and add there your windowing system initialization, the rest parts are cross-platform.

This test uses GL evaluators ported to OpenGL ES 1.1 and classic teapot model for GL evaluators. This allows to generate high polygon models in runtime for tests.

If you run test with option -tpttess=XXX it creates data for:

80:
    Vertices:  209952
    Faces:     204800

100:
    Vertices:  326432
    Faces:     320000

120:
    Vertices:  468512
    Faces:     460800

125:
    Vertices:  508032
    Faces:     500000

127:
    Vertices:  524288
    Faces:     516128

all values starting from 100 kills Gen6 GPU completely.

I tested this on:
Gen6 GPU (SandyBridge) - kills GPU.
Gen7 GPUs (BayTrail, IvyBridge, Haswell) - works perfectly.
Gen8 GPU (Broadwell) - works perfectly.
Gen9 GPUs (Broxton, SkyLake) - works perfectly.
Comment 3 Mark Janes 2017-02-28 18:26:13 UTC
Do you see similar rendering issues with:

 - Mesa 17.0
 - gfxbench 4.0
Comment 4 Mike Gorchak 2017-02-28 19:17:16 UTC
This is an issue for me, since I'm running all this stuff under QNX and matched versions on Yocto Linux to compare performance and stability. I don't have Mesa 17.x and GFXBench 4.0 ported yet, sorry.
Comment 5 Matt Turner 2017-02-28 20:09:07 UTC
We are not in a position to test QNX. Can you confirm that the problems you see occur in Linux?
Comment 6 Kenneth Graunke 2017-02-28 20:16:05 UTC
Also...we'd really like to try and keep each bug report to one bug, not "sandybridge is broken in multiple programs on multiple versions on multiple OSes".

Regarding your uniform precision mismatching problems, causing shaders to fail to compile, see:
https://bugs.freedesktop.org/show_bug.cgi?id=97532

This is a bug in the application, which you can work around by running GLBenchmark with -skip_load_frames.  We have a workaround we could apply, but it really isn't our bug.
Comment 7 Mike Gorchak 2017-02-28 20:18:57 UTC
> We are not in a position to test QNX. Can you
> confirm that the problems you see occur in Linux?

I'm not asking you test on QNX, this is what I do :) Yes, I tested 2016Q3 and 2016Q4 Intel Graphics Stack Recipe packages as well on Linux. Also did a quick try for some old kernels too. The problem is still reproducible.
Comment 8 Mike Gorchak 2017-02-28 20:21:22 UTC
> Also...we'd really like to try and keep
> each bug report to one bug, not "sandybridge
> is broken in multiple programs on multiple versions on multiple OSes".

Sorry, I know it is not a perfect bug report, just added this as "by the way".

> This is a bug in the application, which you can work
> around by running GLBenchmark with -skip_load_frames.
> We have a workaround we could apply, but it really isn't our bug.

I see, thank you for letting me know for existing workaround!
Comment 9 Tapani Pälli 2018-04-23 06:56:26 UTC
As per comment #6 the glbenchmark 25.1 artefacts were application side issues, resolving this as NOTOURBUG.


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.