Bug 89759 - WebGL OGL ES GLSL conformance test with mesa drivers fails
Summary: WebGL OGL ES GLSL conformance test with mesa drivers fails
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-25 06:27 UTC by Luke
Modified: 2015-03-27 02:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
shader test (1.15 KB, text/plain)
2015-03-25 15:05 UTC, Ilia Mirkin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2015-03-25 06:27:58 UTC
On a GTX 650, the following 2 GLSL tests fail with the nouveau drivers but pass with the nvidia proprietary driver:

https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/ogles/GL/functions/functions_001_to_008.html

test: array_float_vert.test.html
FAIL pixel @ (33, 33 was [182,255,255,255] expected [255,255,255,255]

test: array_float_frag.test.html
FAIL pixel @ (33, 33 was [182,255,255,255] expected [255,255,255,255]
Comment 1 Ilia Mirkin 2015-03-25 14:32:32 UTC
These also fail on r600. This is probably a st/mesa-level or glsl ir-level issue. Haven't gotten any confirmation from anyone using i965, but I'm reassigning this to mesa core.

I suspect that the following is the cause of the trouble:

	b[1] = a[1];
	c[1] += d[1];
	a[1] += 1.0;

If the += 1 gets reordered to before the b[1] = a[1], then we're in trouble. I get cyan as the output, with 182 for the first component, which means that

	if(b[1] == 1.0) q += 2.0;

is failing. Haven't quite figured out how to convert these webgl tests into piglits quite yet, although this one should be easy since it's not input-dependent.
Comment 2 Ilia Mirkin 2015-03-25 14:33:29 UTC
Connor just confirmed that these pass on i965, so most likely a st/mesa issue. [Which doesn't have its own component.]
Comment 3 Ilia Mirkin 2015-03-25 15:05:03 UTC
Created attachment 114617 [details]
shader test

Confirmed that it's the

	a[1] += 1.0;

line causing the trouble. If I comment it out, I get the expected white output.
Comment 4 Ilia Mirkin 2015-03-25 15:32:34 UTC
Looks like the st/mesa copy propagation pass fails... commenting out

v->copy_propagate();

makes the original shader work. Probably not the right forum, but why do we bother with the tgsi optimizations? All the backend drivers do the same things anyway (and in a way that works... :) )
Comment 5 Ilia Mirkin 2015-03-25 18:00:21 UTC
FTR, the issue is that before the copy prop we have

DCL TEMP[1..4], ARRAY(1), LOCAL
DCL TEMP[5..8], ARRAY(2), LOCAL
DCL TEMP[9..12], ARRAY(3), LOCAL
DCL TEMP[13..16], ARRAY(4), LOCAL
DCL TEMP[17..20], ARRAY(5), LOCAL
DCL TEMP[21..24], ARRAY(6), LOCAL
DCL TEMP[25..26], LOCAL

 28: MOV TEMP[25].x, TEMP[14].xxxx
 30: ADD TEMP[14].x, TEMP[14].xxxx, IMM[0].yyyy
 46: FSEQ TEMP[26].x, TEMP[25].xxxx, IMM[0].yyyy

And the copy propagation pass decides to copy-prop TEMP[14] into TEMP[25] on line 46. This ends poorly. Perhaps because file == PROGRAM_ARRAY isn't properly supported by the pass? Not sure. Sent a patch to just remove.
Comment 6 Ilia Mirkin 2015-03-27 02:39:59 UTC
Dave pushed a fix in commit 91e3533481. Thanks for reporting!


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.