Created attachment 128549 [details] simple test case The attached program produces different incorrect result on Intel Skylake (using Mesa 13.0.2 or master). Modifying the vertex shader to use: "3 + gl_VertexID" is enough to get the expected behavior.
Created attachment 128550 [details] expected result Output using: nouveau, r600 and intel haswell
Created attachment 128551 [details] result on skylake lspci: 00:02.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 07)
In case it's not obvious, the issue is that gl_VertexID does not appear to get the proper base offset. There are tests for this in piglit, which presumably don't fail on SKL. So it means that this test is doing something odd -- one thing is that it doesn't have a VBO. Although I thought there were piglit tests for that too.
Created attachment 128562 [details] [review] hackpatch The attached hack-patch "fixes" it. I guess the condition in question needs to look at the nr_buffers as set a few lines below, not the vb.nr_enabled ones. As I don't have full visibility of the programming model, I'll let someone else sort out the precise way this needs to be resolved.
Thanks for the report and simple test! Here's a patch to fix the issue: https://lists.freedesktop.org/archives/mesa-dev/2016-December/138593.html Would you be willing to contribute a Piglit test which reproduces this bug? It should be pretty straightforward to port your existing sample code from SDL to the Piglit framework. Doing that means that we'll regression test this on all drivers in the future, meaning it's more likely to not break in the future. Thanks again!
Fixed in Mesa master by: commit 8fc5443a2b39aaa8292984f7225a2c7968d568ae Author: Kenneth Graunke <kenneth@whitecape.org> Date: Mon Dec 19 11:21:27 2016 -0800 i965: Don't bail on vertex element processing if we need draw params
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.