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.
Created attachment 129986 [details] look at statue butt - there a lot of blue/violet dots and lines.
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.
Do you see similar rendering issues with: - Mesa 17.0 - gfxbench 4.0
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.
We are not in a position to test QNX. Can you confirm that the problems you see occur in Linux?
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.
> 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.
> 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!
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.