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!


bug/show.html.tmpl processed on Feb 27, 2017 at 15:46:06.
(provided by the Example extension).