Investigate ways to make more content work with SH_ENFORCE_PACKING_RESTRICTIONS on Windows on ANGLE renderer

[GoogleCodeExporter]

We have a partner here that has a WebGL application that does not work on 
Windows with the ANGLE renderer with SH_ENFORCE_PACKING_RESTRICTIONS.

Somehow, it does work on other platforms with SH_ENFORCE_PACKING_RESTRICTIONS. 
I suppose that that means that other renderers have a higher uniforms limit (?).

I can't share the testcase as-is, and it's not convenient to minimize; but I 
suppose that a testcase would be whatever shader that is just above whatever 
the uniforms limit with packing restrictions is on the ANGLE renderer.

Is there a way to make such content work with SH_ENFORCE_PACKING_RESTRICTIONS 
on Windows on ANGLE renderer? In my limited understanding, that amounts to 
asking: is it possible to raise the uniforms limit of the ANGLE renderer?

Original issue reported on code.google.com by jacob.be...@gmail.com on 22 Jan 2013 at 11:09

[GoogleCodeExporter]

So in other words, what I'm asking for here is can we raise ANGLE's 
MAX_VERTEX_UNIFORM_VECTORS to approximately match typical values found in other 
GL's. Here, the ANGLE renderer gives me 254 uniform vectors, while the NVIDIA 
OpenGL driver gives 1024.

Original comment by jacob.be...@gmail.com on 23 Jan 2013 at 12:17

[GoogleCodeExporter]

Will ANGLE's forthcoming D3D 11 backend increase the number of uniforms 
available to vertex shaders? If so, I don't think anything needs to be done for 
this bug specifically.

Original comment by kbr@chromium.org on 23 Jan 2013 at 12:23

[GoogleCodeExporter]

What about
 - the timeframe between now and when we start using the D3D11 backend in production
 - the users whose hardware/system is only capable of D3D9 ?

Original comment by jacob.be...@gmail.com on 23 Jan 2013 at 12:33

[GoogleCodeExporter]

There are three possible places to have issues - the maximum number of uniforms 
available (MAX_VERTEX_UNIFORM_VECTORS), the number of varying vectors available 
(MAX_VARYING_VECTORS), or with the varying packing algorithm (the varyings are 
the data that is output from the vertex shader and passed into the fragment 
shader). The packing restrictions likely have more impact on the varying 
interface.  

You need to figure out which of these is failing.  Unfortunately without a test 
case, it's very difficult for us to help here. If there is some sort of 
compilation failure it should be noted in the shader compile or link log and it 
should give some information what the problem is. 

MAX_VERTEX_UNIFORM_VECTORS is already at the maximum we can do in on DX9 (there 
on only 256 constants and we need to reserve 2 for internal usage).  Similarly 
with MAX_VARYING_VECTORS - 10 is the maximum we can do on DX9 API. GL drivers 
can do more because they aren't artificially restricted by an old API.  If an 
application tries to use more uniforms or varyings than the limit this is 
really considered an application bug. There are per-implementation limits that 
can be queried. 

If there is merely a bug in ANGLE's varying packing algorithm, we'd be happy to 
fix it if you can narrow down what the problem is or give us a reproducer.

In ANGLE-DX11 we will be able to expose more uniform vectors. 

BTW - if this application is constrained by the ANGLE uniform/varying limits - 
good luck getting it to work on *actual* ES2 hardware. 

Original comment by dan...@transgaming.com on 23 Jan 2013 at 1:29

[GoogleCodeExporter]

Thanks for the explanation. The shader compile error we get is "ERROR: too many 
uniforms" from

http://mxr.mozilla.org/mozilla-central/source/gfx/angle/src/compiler/Compiler.cp
p#204

Which is why I thought that it would be about MAX_VERTEX_UNIFORM_VECTORS. Maybe 
I misunderstoud though.

I didn't realize that the 256 uniforms limitation was inherent to DX9.

Also, at this stage there is no definite reason to believe that this would be a 
bug in ANGLE. We have to look into the actual shaders to find out.

I understand now that the idea to address this only in the DX11 backend is the 
only thing to do here. Thanks.

(Feel free to close as INVALID, or repurpose this bug into the future DX11 
solution tracking bug).

Original comment by jacob.be...@gmail.com on 23 Jan 2013 at 3:51

[GoogleCodeExporter]

Ok that specific error is coming from the SH_ENFORCE_PACKING_RESTRICTIONS test, 
and it could be caused by having a lower MAX_VERTEX_UNIFORM_VECTORS.  Does that 
app work in ANGLE if you don't turn the ENFORCE_PACKING_RESTRICTIONS option on? 
 If so - that like means the app is working because of implementation-specific 
optimizations.

Original comment by dan...@transgaming.com on 23 Jan 2013 at 4:04

[GoogleCodeExporter]

Yes, it is working in ANGLE without ENFORCE_PACKING_RESTRICTIONS. Thanks for 
the explanation, I will explain that to the application developer.

Original comment by jacob.be...@gmail.com on 23 Jan 2013 at 4:48

[GoogleCodeExporter]

The developer has now posted a link to his app on public_webgl, so I assume 
that it's OK to paste here:

http://test-player.actisku.com/tests/cppjs/crypt_no_native_sdk_2012_12_30.html

Original comment by jacob.be...@gmail.com on 23 Jan 2013 at 9:17

[GoogleCodeExporter]

Original comment by c...@chromium.org on 7 Dec 2013 at 4:05

[GoogleCodeExporter]

Original comment by geofflang@chromium.org on 10 Dec 2013 at 3:49