|
d7b1ab58
|
2016-12-12T14:42:19
|
|
Fix up translator style.
Using git cl format.
BUG=angleproject:650
Change-Id: I7d3f98d2b0dcfb0a8de6c35327db74e55c28d761
Reviewed-on: https://chromium-review.googlesource.com/419059
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
89dd8f37
|
2016-11-09T12:59:30
|
|
Remove invariant declaration in vertex shader for translation from ESSL 3.00 to GLSL <= 4.1
This is a follow-up patch of
https://chromium-review.googlesource.com/408569. This CL removes
invariant declaration in ESSL 3.00 vertex shader, such like:
"
out vec4 foo;
invariant foo;
"
This CL also adds the workarounds in libANGLE.
BUG=chromium:639760
TEST=webgl2_conformance
Change-Id: I568ab51a9a2f5da10d1aff0b63aae8805097e081
Reviewed-on: https://chromium-review.googlesource.com/409157
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
45bcc784
|
2016-11-07T13:58:48
|
|
translator: Scope all classes with "sh".
I was seeing an odd problem with our PoolAlloc conflicting with the
glslang/Vulkan TIntermNode, so the fix was to move everything to a
separate namespace.
The bison grammars are also regenerated. No functional changes.
BUG=angleproject:1576
Change-Id: I959c7afe4c092f0d458432c07b4dcee4d39513f3
Reviewed-on: https://chromium-review.googlesource.com/408267
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
acb4b81a
|
2016-11-07T13:50:29
|
|
translator: Put ShaderLang APIs in "sh" namespace.
Working with glslang in Vulkan means we are static linking libANGLE
with functions that have the same name as our translator APIs. We
can fix this by scoping our APIs. We don't need to scope the types
of the file, since they don't conflict.
This will require a follow-up patch to remove the unscoped APIs
once we switch over Chromium.
We also scope TCompiler and some related classes to avoid multiply
defined link errors with glslang.
BUG=angleproject:1576
Change-Id: I729b19467d2ff7d374a82044b16dbebdf2dc8f16
Reviewed-on: https://chromium-review.googlesource.com/408337
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
705a9194
|
2016-08-29T10:05:27
|
|
Reland "Remove invariant qualifier for input in fragment shader"
This relands https://chromium-review.googlesource.com/#/c/400005/.
ESSL and GLSL are not consistent on invariant matching in vertex shader
and fragment shader. See the following rules:
ESSL 1.00 - input and output must match
ESSL 3.00 - only output, inputs cannot be declared as invariant.
GLSL 1.10.59 - does not exist
GLSL 1.20.8 - input and output must match
GLSL 1.30.10 - input and output must match
GLSL 1.40.8 - input and output must match
GLSL 1.50.11 - input and output must match
GLSL 3.30.6 - input and output must match
GLSL 4.00.9 - input and output must match
GLSL 4.10.6 - input and output must match
GLSL 4.20.11 - input can omit invariant
GLSL 4.30.8 - input can omit invariant
GLSL 4.40.9 - input can omit invariant
GLSL 4.50.5 - input can omit invariant
Since GLSL 4.20, invariant qualifier description were changed to:
"
Only variables output from a shader (including those that are then input
to a subsequent shader) can be candidates for invariance. This includes
user-defined output variables and the built-in output variables. As only
outputs need be declared with invariant, an output from one shader stage
will still match an input of a subsequent stage without the input being
declared as invariant.
"
It's not very clear if input in fragment can be declared as invariant.
Mesa driver disallows use of input declared as invariant in fragment
shader, while other drivers may allow it. This CL removes invariant
declaration for input in fragment shader except AMD driver in Linux.
AMD's driver obviously contradicts the spec by forcing invariance to
match between vertex and fragment shaders.
BUG=chromium:639760, chromium:659326
TEST=conformance/glsl/misc/shaders-with-invariance.html and
conformance/glsl/bugs/invariant-does-not-leak-across-shaders.html
Change-Id: I0aa9be14f0cee7a11a249c91fba27c570c52ca1b
Reviewed-on: https://chromium-review.googlesource.com/404228
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
|
|
7e921616
|
2015-10-01T14:00:04
|
|
Add texture2DRect -> texture conversion for OpenGL core profile
BUG=534114
Change-Id: If0e1557a2399436b1b160407ced2d265f42df5f0
Reviewed-on: https://chromium-review.googlesource.com/303761
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tryjob-Request: Jamie Madill <jmadill@chromium.org>
Tested-by: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|
|
b18609b9
|
2015-07-16T14:13:11
|
|
Implement ES 2,3 parts of EXT_blend_func_extended for shader translation
Exposes gl_SecondaryFragColor, glSecondaryFragData[] and
gl_MaxDualSourceDrawBuffers to GLES SL 1.0.
Relaxes rules for undefined output locations for GLES SL 3.0
and exposes gl_MaxDualSourceDrawBuffers.
If the output GL context is GL ES 2.0 or 3.0:
The emulation layer is expected to turn on EXT_blend_func_extended
if the output GL context supports it.
If the output GL context is GL:
The emulation layer is expected to turn on EXT_blend_func_extended
if the output GL context supports ARB_blend_func_extended or if GL
context is 3.2 or later.
If the source shader spec is GLES SL 2.0: The emulation layer is
expected to inspect the shader compilation output variables upon
linking. If output target is GL SL, the emulation layer should bind
color location 0, index 1 to "angle_SecondaryFragColor" if variable
"gl_SecondaryFragColorEXT" is used. Alternatively, emulation layer
should bind "angle_SecondaryFragData" to locations 0,1,2,3,..., all
color index 1, if "gl_SecondaryFragData" array is used.
(The caller can not bind the locations or specify output variables.)
If the source shader spec is GLES SL 3.0:
The emulation layer is expected to do location auto-resolve of the
the output variables that have undefined output locations that have
not been bound by the caller.
(The caller can not use gl_ built-ins, so nothing to do with those.)
BUG=angleproject:1085
TEST=angle_unittest
Change-Id: I5cafe205b0c29478b0dcd24aa89a7b0000f5d046
Reviewed-on: https://chromium-review.googlesource.com/287580
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Kimmo Kinnunen <kkinnunen@nvidia.com>
|
|
ad0d0799
|
2015-04-08T14:25:06
|
|
Expand ShShaderOutput for different GLSL versions
BUG=angleproject:968
Change-Id: I2d4c0a8e9a91a940922da4501c22124da0c0399c
Reviewed-on: https://chromium-review.googlesource.com/264840
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
05b6b7fc
|
2015-03-02T17:08:09
|
|
Add an SH_GLSL_CORE_OUTPUT profile.
So we could generate shaders for Apple using core GL profile.
By switching to core profile, we still pass most WebGL conformance tests 1.0.2 on Linux, but not all, so apparently more work is needed.
However, I think it's OK to check this CL in because this output profile will be only used behind a chromium switch.
BUG=angleproject:933
TEST=webgl conformance tests
Change-Id: Iad70e1aebf82349d3fc5f4116c1d6bc4448193fd
Reviewed-on: https://chromium-review.googlesource.com/255282
Tested-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
46485086
|
2014-04-15T13:12:50
|
|
Implement EXT_shader_texture_lod
BUG=angle:551
Change-Id: I81d7574a15861f1b24ddf6147cf71adbf20e10f3
Reviewed-on: https://chromium-review.googlesource.com/194960
Tested-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
|
|
17732823
|
2013-08-29T13:46:49
|
|
Moved the compiler source files into directories based on their project and added a compiler.gypi to generate the compiler projects.
|