With this CL we have the ability to create Vulkan test configs and run
basic tests, although the only thing that works is creating a Vulkan
Renderer using the extension.
BUG=angleproject:1319
Change-Id: I8ad17bba01241334be7da16e68fea38762ca6a20
Reviewed-on: https://chromium-review.googlesource.com/367750
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
atan(y, x) is not always returning expected results on NVIDIA OpenGL
drivers between versions 367 and 375. Work around this by emulating
atan(y, x) using the regular atan(x) function. A fix to the driver is
expected in a future release.
It is most convenient to implement the vector atan(y, x) functions by
using the scalar atan(y, x) function. Support for simple dependencies
between emulated functions is added to BuiltInFunctionEmulator. In the
current implementation one function is allowed to have at most one
other function as its dependency.
BUG=chromium:672380
TEST=angle_end2end_tests
Change-Id: I9eba8b0b7979c7c7eaed353b264932e41830beb1
Reviewed-on: https://chromium-review.googlesource.com/419016
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Result of -float is wrong on Intel Mac 10.11 drivers. Replace -float
with 0.0 - float to work around this issue.
BUG=308366
BUG=672380
Change-Id: I53bc2eda7259fff5805bec39896fc7b7a6eaf665
Reviewed-on: https://chromium-review.googlesource.com/417169
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
For loop unrolling is not used and causes the translator fuzzer to find
a hang when unrolling tons of nested loops (duh).
Also remove MMap.h which was unused.
This is essentially a revert of https://codereview.appspot.com/4331048
BUG=chromium:665255
Change-Id: Id6940f7e306d4ed53bc992f751e9ffe733190f17
Reviewed-on: https://chromium-review.googlesource.com/412023
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
We only need the typed variable information in our header files.
The entry point and other enum info can be encapsulated better
in the cpp files that call through to the translator. The only
tricky one is the compile options, which we return from our
implementation - put the typedef for these in the ShaderVars
header to fix this.
This should partially work around the problem of shaderlang
for Vulkan and ANGLE's translator (also ShaderLang) using some
identifiers with the same names.
BUG=angleproject:1576
Change-Id: I43c530486498c210796b9e197a6780bf2f7b3afb
Reviewed-on: https://chromium-review.googlesource.com/412423
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
AMD driver in Linux requires invariant qualifier to match between
shaders even for GLSL >= 4.2. This conflicts with ESSL 3.0 which
disallows invariant qualifier in fragment shader. Remove invariant
qualifier in vertex shader to workaround AMD driver bug.
BUG=chromium:639760
TEST=webgl2_conformance
Change-Id: Id5adf7e7032105486df90a1f200471ea81ee5c36
Reviewed-on: https://chromium-review.googlesource.com/411917
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
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>
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>
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>
On some Mac drivers with shader version 4.1, they will
treat unused std140 and shared uniform blocks' members as inactive. However,
WebGL2.0 based on OpenGL ES3.0.4 requires all members of a named uniform block
declared with a shared or std140 layout qualifier to be considered active.
The uniform block itself is also considered active.
This workaround is to reference all members of unused std140 and shared uniform blocks
at the beginning of the vertex/fragment shader's main().
BUG=chromium:618464
TEST=UniformBufferTest.ActiveUniformBlockNumber
Change-Id: I18da4e2b61b0170068bf5ea38ce54667b0737780
Reviewed-on: https://chromium-review.googlesource.com/395648
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
On some Mac drivers with shader version 4.1, they will
treat unused std140 and shared uniform blocks' members as inactive. However,
WebGL2.0 based on OpenGL ES3.0.4 requires all members of a named uniform block
declared with a shared or std140 layout qualifier to be considered active.
The uniform block itself is also considered active.
This workaround is to reference all members of unused std140 and shared uniform blocks
at the beginning of the vertex/fragment shader's main().
BUG=chromium:618464
TEST=UniformBufferTest.ActiveUniformBlockNumber
Change-Id: I1d2c5e3e8da04786ac6a37fd26f7bb9c14cd76ed
Reviewed-on: https://chromium-review.googlesource.com/387169
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
On some Intel drivers, calling function isnan() on highp float will get wrong
answer. This patch work arounds this bug by using an expression to emulate
this function.
BUG=chromium:650547
Change-Id: I5bc5e0352c434f42cd2c55103a74f9f7ba51a72c
Reviewed-on: https://chromium-review.googlesource.com/389834
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
On some Intel D3D drivers, evaluating unary minor operator on an
integer variable may get wrong answer in vertex shader.
This patch works around this bug by replacing -(int) with ~(int)+1
on Windows Intel.
BUG=chromium:644033
Change-Id: I0af719e84d618a33f25bcb33bde0c381fb462a31
Reviewed-on: https://chromium-review.googlesource.com/381675
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Condition calculation in for and while loops has bug on Intel Mac. Work
around it by converting "CONDITION" to "CONDITION && true".
This CL also adds previous SH_EMULATE_ABS_INT_FUNCTION workaround to
the ANGLE GL back-end on OSX
BUG=chromium:644669
TEST=deqp/functional/gles3/shaderloop_for/while.html
Change-Id: I910f662b054f259fcb601b9938841b3a2d066840
Reviewed-on: https://chromium-review.googlesource.com/381678
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Qiankun Miao <qiankun.miao@intel.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
The timing restrictions code is not in use and not updated for ESSL3,
so it is better to remove it to make refactoring the AST easier.
It can also be argued that perfect prevention of shader timing attacks
is not feasible due to factors that are not under control of ANGLE,
such as fixed function color compression in GPUs. Such color
compression may make the use of texture bandwidth and thus performance
dependent on the content of a texture regardless of whether a
compressed format is chosen through the API.
SH_DEPENDENCY_GRAPH flag that could only be active together with the
timing restrictions flag is also removed, along with all the code that
was supporting it. The newer CallDAG code is used for different
purposes and is kept.
BUG=angleproject:1490
TEST=angle_unittests
Change-Id: I2cd10e18df366e8e43f7c3af1ca12d2a4bfb2007
Reviewed-on: https://chromium-review.googlesource.com/384511
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
The flag is not used in chrome. We decide to do per emulation per flag.
BUG=chromium:642227
Change-Id: I936d53e5015186e35e672d0cb51c853a941582d2
Reviewed-on: https://chromium-review.googlesource.com/379077
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
abs(i) where i is an integer returns unexpected result in Intel Mac.
This works around the issue by emulating abs(i) manually.
BUG=chromium:642227
TEST=deqp/functional/gles3/shadercommonfunction.html
Change-Id: I2a41e0f4bcb0766109d651e663283b1760468017
Reviewed-on: https://chromium-review.googlesource.com/377628
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
GLSL function texelfetchoffset will be translated into texture.Load in
ANGLE. In D3D there is a note that When one or more of the coordinates
in Location exceeds the u, v, or w mipmap level dimensions of the
texture, Load returns zero in all components, but in glsl there is no
such restriction, which will cause the WebGL 2 dEQP test
deqp/functional/gles3/shadertexturefunction/texelfetchoffset.html fail
on Windows with Intel GPU.
Adapted from ExpandIntegerPowExpressions.cpp, this patch adds a
translation from texelFetchOffset into texelFetch to work around this
issue.
BUG=angleproject:1469
Change-Id: Iecfb9570472036acf5960789bdb1a63f191316be
Reviewed-on: https://chromium-review.googlesource.com/367883
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
There were two issues with the current implementation:
* The GetDimensions function already takes into account the base level of the
SRV.
* The GetDimensions function returns doesn't return valid sizes for levels
that don't exist in the SRV. Instead, manually do the lod offset.
BUG=angleproject:931
BUG=angleproject:1316
TEST=dEQP-GLES3.functional.shaders.texture_functions.texturesize.sampler2d_fixed_vertex
Change-Id: I63259b563a42b93b73949e0ef7ac412099a42f13
Reviewed-on: https://chromium-review.googlesource.com/376099
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Compute shaders can be now compiled and linked to create programs.
Some tests are added to verify successful and unsuccessful compute
shader linking.
The patch also replaces std::array<int, 3> with a custom struct
WorkGroupSize.
BUG=angleproject:1442
TEST=angle_end2end_tests
TEST=angle_unittests
Change-Id: I4ab0ac05755d0167a6d2a798f8d7f1516cf54d84
Reviewed-on: https://chromium-review.googlesource.com/366740
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
This is implemented as a compiler option which is enabled by default
when outputting to desktop GLSL version 130 and greater, which does
not support this #pragma in fragment shaders. As a workaround, and for
better compatibility on desktop OpenGL drivers, this pragma is also
flattened into the outputs of vertex shaders, and the inputs of ESSL
1.00 fragment shaders.
TEST=conformance/glsl/misc/shaders-with-invariance.html with --enable-unsafe-es3-apis
BUG=629622, angleproject:1293
Change-Id: Ib040230915e639971505ed496d26e804c9d64e68
Reviewed-on: https://chromium-review.googlesource.com/361792
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Support is added for compute shader compilation. There is a small
extension to the parser so that 'local_size_x = ', 'local_size_y = '
and 'local_size_z = ' are supported as layout qualifiers.
A few shader compilation tests are added and one which checks the AST
whether the layout qualifiers are properly parsed.
BUG=angleproject:1442
TEST=angle_unittests
TEST=angle_end2end_tests
Change-Id: I67283797d1cf13fa4ac47faa2a6e66d93a2db867
Reviewed-on: https://chromium-review.googlesource.com/362300
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
The dEQP test for context creation passes.
SH_WEBGL3_SPEC has been added, but it should be considered whether we
should keep it, remove it or rename it. It was added so that there is
a webgl mapping to es 310 shaders. Check Compiler.cpp. The bison file
has been modified so that some tokens from es3 can be also used in
es31 as well.
A separate macro ES3_1_ONLY is added so that some tokens are limited
only for es 310 shaders.
BUG=angleproject:1442
TEST=angle_unittests
Change-Id: I2e5ca227c96046c30dc796ab934f3fda9c533eba
Reviewed-on: https://chromium-review.googlesource.com/360300
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
This overload doesn't take a stripped down version of the variable
information, which makes it possible to handle varying structs
correctly by flattening them as individual variables.
BUG=621031
Change-Id: I367629fce3d17dd7e1f876c5937eb37f3d97c7f4
Reviewed-on: https://chromium-review.googlesource.com/361460
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This will be used by Chromium to check for interface blocks mismatches.
BUG=621031
Change-Id: Ia6cc19e5d7b2a5c33af558d65b87885a6b72cea3
Reviewed-on: https://chromium-review.googlesource.com/359607
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
The main functionality for NV12 texture support through EGL streams has
been added. Updates to the compiler, texture code, and stream code were
added to support binding to external D3D11 NV12 textures. An end2end test
was also added to test sampling of YUV textures and converting to RGB.
There is also a new script to convert BMP files to an NV12 texture ready
to load into D3D11 for testing purposes.
BUG=angleproject:1332
Change-Id: I39b6ec393ea338e2c843fb911acc1b36cd1158a0
Reviewed-on: https://chromium-review.googlesource.com/339454
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Ian Ewell <ewell@google.com>
Reviewed-on: https://chromium-review.googlesource.com/341254
Reviewed-by: Ian Ewell <ewell@google.com>
The main functionality for NV12 texture support through EGL streams has
been added. Updates to the compiler, texture code, and stream code were
added to support binding to external D3D11 NV12 textures. An end2end test
was also added to test sampling of YUV textures and converting to RGB.
There is also a new script to convert BMP files to an NV12 texture ready
to load into D3D11 for testing purposes.
BUG=angleproject:1332
Change-Id: I098940e6f25e113dcc4fc8d22ffed4b5a16fd860
Reviewed-on: https://chromium-review.googlesource.com/339454
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Ian Ewell <ewell@google.com>
Since HLSL can't natively handle samplers in structs, samplers need to
be extracted out of structs into separate variables in the translated
shader code. In HLSL 4.1, samplers that were in structs go into the
normal sampler arrays and are identified by index constants. In other
HLSL versions, samplers that were in structs are translated as uniform
variables.
These transformations are done inside the HLSL output classes, not as
tree transformations. This helps to keep the uniform API provided by
the shader translator intact.
Wherever a struct containing samplers is passed into a user-defined
function, the translated HLSL code passes the separate sampler
variables alongside a struct where the samplers have been removed.
The D3D backend in libANGLE queries the uniform registers of any
samplers that were in uniform structs, and adds them to the register
maps, so that correct sampler state gets assigned to them.
The extracted sampler variables are prefixed with "angle_" instead of
the usual "_" to prevent any name conflicts between them and regular
variables.
BUG=angleproject:504
TEST=angle_end2end_tests,
dEQP-GLES*.functional.shaders.struct.uniform.* (all pass),
dEQP-GLES*.functional.uniform_api.* (most now pass)
Change-Id: Ib79cba2fa0ff8257a973d70dfd917a64f0ca1efb
Reviewed-on: https://chromium-review.googlesource.com/333743
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Trying to compile user-defined functions that have thousands of
parameters introduces some instability in native compilers, so it is
better to reject shaders with large numbers of function parameters
in ANGLE.
The check is only enabled if the SH_LIMIT_EXPRESSION_COMPLEXITY flag
is turned on. The default limit for the number of parameters is 1024,
but it can also be configured.
BUG=angleproject:1338
TEST=angle_unittests
Change-Id: I5c9b7a4e97e67f36e77f969368336fa8fffba1c3
Reviewed-on: https://chromium-review.googlesource.com/331970
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
The spec mandates that the instance name of a block determines how the
active uniform name for this field is reported. However, our handling
of this was a bit bugged. We would include the proper prefix on the
compiler-side, but this mangled the hashing, and was also not strictly
needed. We now also expose the instance name, so we can determine the
proper prefix for variable linking on the GL-side of things. This also
is consistent with how we handle other spec issues, where the GL-side
handles the GL-API specific functionality.
This also allows us to fix name hashing of instanced uniform blocks,
which was previously broken because we would hash the full name of the
active uniform, instead of just the field.
BUG=angleproject:1306
Change-Id: I06ace6dbc3f75fdd8129677360dcc142aa89136e
Reviewed-on: https://chromium-review.googlesource.com/326681
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Translation of samplers to HLSL on D3D11 is changed as follows:
Instead of passing around HLSL sampler and HLSL texture references in
shaders, all references to ESSL samplers are converted to constant
indices within the shader body. Each ESSL sampler is identified by an
unique index. In the code generated to implement ESSL texture functions,
these indices are used to index arrays of HLSL samplers and HLSL
textures to get the sampler and texture to use.
HLSL textures and samplers are grouped into arrays by their types. Each
unique combination of a HLSL texture type + HLSL sampler type gets its
own array. To convert a unique sampler index to an index to one of these
arrays, a constant offset is applied. In the most common case of a 2D
texture and a regular (non-comparison) sampler, the index offset is
always zero and is omitted.
The end goal of this refactoring is to make adding extra metadata for
samplers easier. The unique sampler index can be used in follow-up
changes to index an array of metadata passed in uniforms, which can
contain such things as the base level of the texture.
This does not solve the issues with samplers in structs.
The interface from the point of view of libANGLE is still exactly the
same, the only thing that changes is how samplers are handled inside the
shader.
On feature level 9_3, the D3D compiler has a bug where it can report that
the maximum sampler index is exceeded when in fact it is not. This can
happen when an array of samplers is declared in the shader. Because of
this the new approach can't be used on D3D11 feature level 9_3, but it
will continue using the old approach instead.
BUG=angleproject:1261
TEST=angle_end2end_tests,
dEQP-GLES3.functional.shaders.texture_functions.* (no regressions)
dEQP-GLES3.functional.texture.units.* (no regressions)
Change-Id: I5fbb0c4280000202dc2795a628b56bd8194ef96f
Reviewed-on: https://chromium-review.googlesource.com/320571
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Tryjob-Request: Olli Etuaho <oetuaho@nvidia.com>
In WinRT we only use the HLSL code, so the GLSL/ESSL output code
is not necessary and is only adding to our binary size.
BUG=angleproject:1250
Change-Id: I9363ca3981bde50a230f8353c1bcc09f6ea209cb
Reviewed-on: https://chromium-review.googlesource.com/317358
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Tryjob-Request: Austin Kinross <aukinros@microsoft.com>
Tested-by: Austin Kinross <aukinros@microsoft.com>
These aren't referenced from Chromium code any more.
BUG=chromium:550487
Change-Id: Ie4094667ec5f739efd9f1253ffdb779deaf3cebc
Reviewed-on: https://chromium-review.googlesource.com/319162
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Kenneth Russell <kbr@chromium.org>
Most code using the translator already enables highp with the resources
flag when a shader spec that accepts ESSL3 is used, but for example the
shader_translator utility doesn't. This fix makes sure that highp is
always enabled when a fragment shader written in ESSL3 or newer is being
compiled. This will make shader_translator easier to use for testing
ESSL3 shaders.
BUG=541550
TEST=angle_unittests
Change-Id: Ia1911677c55f3c5d921829a8cbb808847ac8b636
Reviewed-on: https://chromium-review.googlesource.com/305190
Tryjob-Request: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
This works around a Mac driver shader compiler bug that makes many
do-while loops cause GPU-hangs when ran.
BUG=angleproject:891
Change-Id: I29828d6ea9e887ad0ed0c577f1deb41fb632a900
Reviewed-on: https://chromium-review.googlesource.com/302465
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Corentin Wallez <cwallez@chromium.org>
This replaces the dual-use of sh::Attribute, which can be a bit
confusing to people expecting a literal output variable.
Currently not used in Chromium, so should be safe to land.
BUG=angleproject:1146
Change-Id: I436f2bc9dc4ddc3709369cb2baa344c6b13a21a2
Reviewed-on: https://chromium-review.googlesource.com/296683
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
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>
This helps reclaiming memory used by the results when we don't need
them anymore.
BUG=492725
Change-Id: I4bc11be27b23589548120f0dc43e9979bf894089
Reviewed-on: https://chromium-review.googlesource.com/277808
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Dmitry Skiba <dskiba@google.com>
Tested-by: Dmitry Skiba <dskiba@google.com>
Reviewed-by: Dmitry Skiba <dskiba@google.com>
pow(x, y) when y is a certain kind of a constant vector can cause issues on
NVIDIA 331 series drivers. Add an option to replace pow(x, y) with
exp2(y * log2(x)) when y is a constant to work around this issue.
This is done with an AST traverser instead of BuiltInFunctionEmulator, since
there's no mechanism in BuiltInFunctionEmulator to apply the replacements
only to calls where the second parameter is constant.
TEST=WebGL conformance tests
BUG=chromium:477306
Change-Id: Ifb327d72659fca36868439f24705203014b3ce53
Reviewed-on: https://chromium-review.googlesource.com/274279
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
The parser recognizes ESSL3 invariant variable declaration syntax and
marks the variables as invariant.
In ESSL3, invariant out variables can be linked to non-invariant
in variables, so linking checks should now be different depending on
shading language version. A shading language version dependent varying
matching check is added to the translator API to facilitate this.
Tested by deqp/data/gles3/shaders/qualification_order.html after patching
Chrome to use the new linking check API.
A previous revision of this change that broke API compatibility was
reverted since it broke Chromium FYI bots. This revision keeps deprecated
API functionality around for now so that changes can be rolled
step-by-step to Chromium without breakage.
TEST=WebGL 2 conformance tests, angle_unittests
BUG=angleproject:987
Change-Id: Iecb64e3afd23e267ba999bc17f44390affcdfc13
Reviewed-on: https://chromium-review.googlesource.com/269940
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
The parser recognizes ESSL3 invariant variable declaration syntax and
marks the variables as invariant.
In ESSL3, invariant out variables can be linked to non-invariant
in variables, so linking checks should now be different depending on
shading language version. The varying matching check in the translator
API is changed to be shading language version dependent to facilitate
this.
Tested by deqp/data/gles3/shaders/qualification_order.html after patching
Chrome to use the new linking check API.
TEST=WebGL 2 conformance tests, angle_unittests
BUG=angleproject:987
Change-Id: I3982feff7380c4dfc647940ee03a020692dd0c59
Reviewed-on: https://chromium-review.googlesource.com/267663
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
*re-land with Linux fixes, and fix for locations*
This built-in uniform wasn't being collected in VariableInfo.cpp.
Also remove the existing workaround for D3D gl_DepthRange
collection.
BUG=angleproject:991
BUG=478570
Change-Id: Iba84651bfc58f82fd4ce039421874f561f83c348
Reviewed-on: https://chromium-review.googlesource.com/268840
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Build errors on Linux:
error: comparison of integers of different signs: 'const int' and 'const unsigned int'
BUG=angleproject:991
BUG=478570
This reverts commit f1ae954b66.
Change-Id: I217aba1b32dc0e70d6153337a1f0ccef0483a0e1
Reviewed-on: https://chromium-review.googlesource.com/268792
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
This built-in uniform wasn't being collected in VariableInfo.cpp.
Also remove the existing workaround for D3D gl_DepthRange
collection.
BUG=angleproject:991
BUG=478570
Change-Id: Ie254132e37c307323ba9e6e1705d138eea67b520
Reviewed-on: https://chromium-review.googlesource.com/268524
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Also adds a simple unit test checking the pruning
BUG=angleproject:937
BUG=395048
Change-Id: I88440378f66178dcebebcd596f8f80235903f20e
Reviewed-on: https://chromium-review.googlesource.com/264568
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Tested-by: Corentin Wallez <cwallez@chromium.org>
Also adds a simple unit test checking the pruning
BUG=angleproject:937
BUG=395048
Change-Id: I49904c34d1a72949cdc579569967d99c736c7237
Reviewed-on: https://chromium-review.googlesource.com/264415
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Tested-by: Corentin Wallez <cwallez@chromium.org>
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>
The ES3.1 spec, and discussion on Khronos.org, confirm that dEQP is
correct in accepting mismatching centroid specifiers in shader
linkage. Mismatching flat/smooth is still a link error.
Fixes:
shaders.linkage.varying.rules.differing_interpolation_2
Change-Id: I3016f4147e7c1b16b02371ee95866c8daf826212
Reviewed-on: https://chromium-review.googlesource.com/251205
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
We're only using the HLSL code in Windows so
it's not necessary to compile and distribute it on other platforms.
This adds a defined ANGLE_ENABLE_HLSL that can be checked in files that
are used by non-HLSL code as well. Mostly the HLSL code is just not
include by the build system.
Details of the space savings (heavily truncated)
Total change: -165717 bytes
===========================
-606 - Source: angle/src/common/utilities.cpp
-627 - Source: angle/src/compiler/translator/FlagStd140Structs.cpp
-695 - Source: /usr/include/c++/4.8/bits/stl_algo.h
-710 - Source: angle/src/compiler/translator/TranslatorHLSL.cpp
-713 - Source: angle/src/compiler/translator/IntermNode.h
-863 - Source: /usr/include/c++/4.8/bits/stl_map.h
-935 - Source: angle/src/compiler/translator/blocklayout.cpp
-1515 - Source: angle/src/compiler/translator/BuiltInFunctionEmulator.cpp
-1655 - Source: angle/src/compiler/translator/UnfoldShortCircuit.cpp
-2375 - Source: /usr/include/c++/4.8/bits/vector.tcc
-3135 - Source: angle/src/compiler/translator/RewriteElseBlocks.cpp
-4656 - Source: angle/src/compiler/translator/UtilsHLSL.cpp
-5265 - Source: angle/src/compiler/translator/BuiltInFunctionEmulatorHLSL.cpp
-6505 - Source: /usr/include/c++/4.8/bits/stl_tree.h
-11480 - Source: angle/src/compiler/translator/UniformHLSL.cpp
-13580 - Source: angle/src/compiler/translator/StructureHLSL.cpp
-18964 - Source: ??
(constant strings and a few vtbls)
-89332 - Source: angle/src/compiler/translator/OutputHLSL.cpp
Change-Id: I23ccc98abd0a21f847dd34f9482800b3ba679d56
Reviewed-on: https://chromium-review.googlesource.com/251528
Tested-by: bratell at Opera <bratell@opera.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
This implements the rounding as specified in WEBGL_debug_shader_precision
extension proposal for desktop GLSL and ESSL output. The bulk of the new
functionality is added in the form of a new EmulatePrecision AST
traverser, which inserts calls to the rounding routines angle_frm and
angle_frl in the appropriate places, and writes the rounding routines
themselves to the shader.
Compound assignments which are subject to emulation are transformed from
"x op= y" to "angle_compound_op_frm(x, y)", a call to a function which
does the appropriate rounding and places the result of the operation to
x.
The angle_ prefixed names should not clash with user-defined names if
name hashing is on. If name hashing is not on, the precision emulation
can only be used if the angle_ prefix is reserved for use by ANGLE.
To support the rounding routines in output, a new operator type is added
for internal helper function calls, which are not subject to name
hashing.
In ESSL output, all variables are forced to highp when precision
emulation is on to ensure consistency with how precision emulation
performs on desktop.
Comprehensive tests for the added code generation are included.
BUG=angle:787
Change-Id: I0d0ad9327888f803a32e79b64b08763c654c913b
Reviewed-on: https://chromium-review.googlesource.com/229631
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Chromium builds a std::map with ShBuiltInResources as part of the key.
Comparator for == and < are needed for the map implementation.
Currently Chromium uses memcmp as the comparator. Padding
in ShBuiltInResources causes uninitialized reads.
Fix this by clearing the padding with memset during ShBuiltInResources
initialization.
Change-Id: I78aa3c59ce165503831aa2a67c96cf8af316c152
Reviewed-on: https://chromium-review.googlesource.com/223431
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Shannon Woods <shannonwoods@chromium.org>
This is needed to effectively use the new APIs to get shader variable info.
BUG=angle::770
TEST=ShaderVariableTest
Change-Id: Ia591eb567868ebe898f4a7449c64167ad212f59b
Reviewed-on: https://chromium-review.googlesource.com/221388
Tested-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
After this patch, it is possible to set a flag to change
EXT_draw_buffers extension directives to NV_draw_buffers in ESSL.
This enables users of ANGLE to emulate EXT_draw_buffers by using
NV_draw_buffers in combination with GLES3.0.
Change-Id: I5dacdbd6cd0d0362424ea3791557342c42efd4bd
Reviewed-on: https://chromium-review.googlesource.com/219941
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Some block field types, such as nested structs, were bugged. This
only affects our "CollectVariables" path, not our current HLSL
UBO path.
BUG=angle:466
Change-Id: I2b8daf58aa7ec1ad06a80d38f57e76087eacccdc
Reviewed-on: https://chromium-review.googlesource.com/213503
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Nicolas Capens <capn@chromium.org>
Instead of only storing structure information in Varyings, Uniforms
and Interface Block Fields, store it in the base class. Also only
store base variable information for struct fields, instead of fully
typed information. This works because stuff like interpolation type,
invariance, and other properties are for the entire variable, not
individual fields.
Also add new fields for interface block instance name, varying
invariance and structure name for all struct types.
BUG=angle:466
Change-Id: If03fc071e6becb7aad6dea5093989bba7daee69e
Reviewed-on: https://chromium-review.googlesource.com/213501
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Nicolas Capens <capn@chromium.org>
This will allow us to use these methods when compiling the translator
as a DLL.
BUG=angle:466,697
Change-Id: Ic9169fb7c69fe0bf5f98addfc128a30ee6b2159d
Reviewed-on: https://chromium-review.googlesource.com/208752
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Each new entry point corresponds to one of the variable types:
varyings, attributes, uniforms, output variables, and interface
blocks. They return a pointer to the vector with all of the
parsed variables, which then the app can copy to its own memory.
Currently we do not support the staticUse field in the HLSL
translator.
BUG=angle:466
Change-Id: I7dc09e761ab070feef5360ad27740110c44853b3
Reviewed-on: https://chromium-review.googlesource.com/208750
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Nicolas Capens <capn@chromium.org>
This allows the API to query for clear type introspection into the
parsed GL types from the translator. The returned types are not
expanded and have properly nested fields.
This patch uses the types from ShaderVars.h to return GL type
information. The app must include this header to get access to
the types structs.
BUG=angle:466
Change-Id: I28ad0d6f11a964804dd234ef0d00651f665d1ae3
Reviewed-on: https://chromium-review.googlesource.com/208751
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
This returns the uniform index that we assigned for default uniforms.
All the dependent structure offsets can be determined from the base
register, so we won't have to store uniform information in the shader
variable.
BUG=angle:466
Change-Id: I0dd05251e8dba00c20d09fd865dfb150de56738e
Reviewed-on: https://chromium-review.googlesource.com/207254
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Nicolas Capens <capn@chromium.org>
If one of the parameters is a vec/mat, expand it into scalars.
This is to work around Linux NVIDIA/AMD and Mac NVIDIA driver bugs.
BUG=angle:695
TEST=webgl conformance test
Change-Id: I35e1e25167d99f873dcb03bfb57a30e84b1aeed5
Reviewed-on: https://chromium-review.googlesource.com/207479
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Zhenyao Mo <zmo@chromium.org>
The shader translator can return the assigned register for a
block via a new API. This will let us delete the member variable
in interface blocks for the register -- a nice thing for GLSL.
BUG=angle:466
Change-Id: I9bc38e0cd031e32f90787be42c2324fc7c79dbf9
Reviewed-on: https://chromium-review.googlesource.com/206828
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Nicolas Capens <capn@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Instead of duplicating GL header define values, explictly return
GLenum for variable queries in the shader inspection API. This
reduces the duplicate defines in the shader compiler header.
BUG=angle:466
Change-Id: Iddaaff597b188251fa2e546f352bf77ab3ac43bc
Reviewed-on: https://chromium-review.googlesource.com/205860
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Nicolas Capens <capn@chromium.org>
Instead of duplicating GL header define values, explictly return
GLenum for variable queries in the shader inspection API. This
reduces the duplicate defines in the shader compiler header.
BUG=angle:466
Change-Id: If631b20ce68747297a946e1371def7709027a613
Reviewed-on: https://chromium-review.googlesource.com/204937
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
This is useful for determining if we are compiling to a D3D9 or D3D11
shader outside of the internal translator classes.
BUG=angle:656
Change-Id: Ib1c1d3de569edaa2b65c24c09d05aa4dd229d3e4
Reviewed-on: https://chromium-review.googlesource.com/201564
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
This will avoid Chrome source having to be updated each time that ANGLE's
ShBuiltInResources changes.
BUG=374942
Change-Id: If54dba8351de9b261ff269e885f231547c08ff0a
Reviewed-on: https://chromium-review.googlesource.com/200171
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Shannon Woods <shannonwoods@chromium.org>
We use hashing to map all variables/strcuture field names, etc,
so we no longer need this option.
Checked with Firefox and WebKit, they no longer use this option
either. Time to remove it.
Change-Id: Ie3e79b91a05258b04af419a9c42b2fd1b00e67c4
Reviewed-on: https://chromium-review.googlesource.com/189236
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189568
1) Before this workaround is hardwired on mac, now we move it behind a compil
2) Fix the issue where "break" inside the loop isn't handled while unrolled.
BUG=338474
TEST=webgl conformance test sampler-array-using-loop-index.html
Change-Id: I4996a42c2dea39a8a5af772c256f8e3cb383f59a
Reviewed-on: https://chromium-review.googlesource.com/188079
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Zhenyao Mo <zmo@chromium.org>
Conflicts:
include/GLSLANG/ShaderLang.h
src/compiler/translator/ValidateLimitations.cpp
Change-Id: I546197bd7df1634ebccdd380be14c3250cd56151
Reviewed-on: https://chromium-review.googlesource.com/189061
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Zhenyao Mo <zmo@chromium.org>
We replace "a || b" with "a ? true : b",
"a && b" with "a ? b : false".
This is to work around short circuiting bug in Mac drivers.
ANGLEBUG=482
TEST=webgl conformance tests
R=alokp@chromium.org, kbr@chromium.org
Review URL: https://codereview.appspot.com/14529048
Conflicts:
src/build_angle.gypi
src/compiler/translator/Compiler.cpp
Change-Id: Ic2384a97d58f54294efcb3a012deb2007a9fc658
Reviewed-on: https://chromium-review.googlesource.com/178996
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Tested-by: Shannon Woods <shannonwoods@chromium.org>
Use ANGLE_TRANSLATOR_STATIC to enforce a static build of the translator in
chromium.
This prevents strange warnings from defining COMPONENT_BUILD=0.
Also rename COMPILER_IMPLEMENTATION to ANGLE_TRANSLATOR_IMPLEMENTATION
for better consistency in chromium.
ANGLEBUG=477
R=zmo@chromium.org
BUG=
Instead of parsing them indirectly from HLSL, the pointer will allow us to more flexibly
support new types, especially compound types such as structures.
TRAC #23754
Signed-off-by: Nicolas Capens
Signed-off-by: Shannon Woods
This is an incompatible API change, but one which is necessary in
order to improve correctness of the code. The API version in
ShaderLang.h is updated and, unfortunately, the define renamed to
something less ambiguous due to conflicts on some Android buildbots.
Temporary patches in Chromium and WebKit will be landed separately to
support this upgrade.
BUG=403,404,405,406,407,408,409
Review URL: https://codereview.appspot.com/7300058
Conflicts:
include/GLSLANG/ShaderLang.h
git-svn-id: https://angleproject.googlecode.com/svn/branches/dx11proto@1960 736b8ea6-26fd-11df-bfd4-992fa37f6226
array index clamping to use the clamp intrinsic. This works more
reliably on pure OpenGL ES devices and on Windows.
Added a mechanism in ShBuiltInResources to choose the strategy for
array index clamping.
BUG=none
TEST=various out-of-bounds array indexing tests and various WebGL content
Review URL: https://codereview.appspot.com/7194051
git-svn-id: https://angleproject.googlecode.com/svn/branches/dx11proto@1798 736b8ea6-26fd-11df-bfd4-992fa37f6226
1) We use BuiltInResources to pass the hash function to
ANGLE, deciding whether we applies hash function or not.
2) We use 64 bits hashing function, because 64 bits is 16
bytes using hex representation, plus the "webgl_" prefix,
we can keep the names under 128 (WebGL allows 5 levels of
nesting in structures). If chooseing 128 bits, we will
go beyond 128 characters, and some drivers can't handle
that safely.
ANGLEBUG=315
Review URL: https://codereview.appspot.com/6822077
git-svn-id: https://angleproject.googlecode.com/svn/branches/dx11proto@1466 736b8ea6-26fd-11df-bfd4-992fa37f6226
Description of the algorithm:
http://code.google.com/p/mvujovic/wiki/ShaderControlFlowAnalysis
This flag is one potential solution to timing attacks on textures containing cross-domain content
or user agent data.
This kind of analysis could be useful for both WebGL and CSS Shaders.
The SH_TIMING_RESTRICTIONS flag will reject a shader if it uses texture dependent data to affect
control flow.
Other ways of affecting shader timing such as using NaNs in basic arithmetic operations or using
built-in functions (e.g. atan) with different inputs are still under investigation.
Issue=329
Review URL: http://codereview.appspot.com/6195062/
git-svn-id: https://angleproject.googlecode.com/svn/trunk@1101 736b8ea6-26fd-11df-bfd4-992fa37f6226
This is implemented by adding a new compile option SH_EMULATE_BUILT_IN_FUNCTIONS. The emulated functions are names as webgl_originalName_emu so there will never be naming conflicts.
At the moment only three functions are emulated: normalize, abs, sign. Also, the compile option will emulate all three. However, the mechanism to emulate only a selected subset is also imeplemented. It can be turned on easily.
ANGLEBUG=196
TEST=with this option, the failed test with abs.frag passes.
Review URL: http://codereview.appspot.com/4916043
git-svn-id: https://angleproject.googlecode.com/svn/trunk@738 736b8ea6-26fd-11df-bfd4-992fa37f6226
With this CL, we have the option to select a code output backend: GLSL, GLSL ES, or HLSL.
Note that we always emit the highest supported float precision for fragment shader due to anglebug 168. Although this is a temporary solution, it's not against GLSL ES spec, because it's ok for implementation to upgrade precision.
Tested with WebGL conformance test suite, GLES2 conformance test suite (only failed 2/1198), and a few webgl demos, including worlds of webgl, aquarium, etc.
anglebug=81
test=translator emitting correct GLSL ES code when ES2 backend is selected.
Review URL: http://codereview.appspot.com/4550129
git-svn-id: https://angleproject.googlecode.com/svn/trunk@687 736b8ea6-26fd-11df-bfd4-992fa37f6226
The name mapping happens when an identifier is longer than 32 characters. The name mapping is behind a flag, so it won't happen by default. Also, functions to query the mapped names are added.
The purpose of this CL is for the drivers that can't handle long names. For example, linux NVIDIA driver can't handle 256 character name, whereas WebGL spec requires that.
This CL also fixes the issue that some of the TIntermSymbols' ids are 0s.
ANGLEBUG=144
TEST=test manually with shaders with long identifier names.
Review URL: http://codereview.appspot.com/4428058
git-svn-id: https://angleproject.googlecode.com/svn/trunk@619 736b8ea6-26fd-11df-bfd4-992fa37f6226
This makes debugging and profiling using PIX a lot more convenient. The top level of events are the GLES calls with their arguments. Those can be expanded to see the D3D calls that were issued for a particular GLES call.
When PIX is attached, the shaders are saved out to temporary files and referenced from the translated HLSL shaders via #line directives. This enabled source level debugging of the original GLSL from PIX for pixel and vertex shaders. The HLSL is also saved to a temporary file so that intrinsic functions like texture2D can be stepped into.
It also avoids creating a text file in the current working directory, which has continued to be an issue.
I made the dependency on d3d9.dll static again so it can be accessed by GetModuleHandle witihin DllMain.
I added an EVENT macro that issues D3DPERF_BeginEvent and D3DPERF_EndEvent around a C++ block. I replaced TRACE with EVENT for all the entry points.
I removed the tracing of shader source since the source is visible in PIX.
The means by which the filename of the temporary shader file is passed into the shader compiler is a little clunky. I did it that way to avoid changing the function signatures and breaking folks using the translator.
I plan to make the compiler respect #pragma optimize so that optimization can be disabled for debugging purposes. For now it just disables shader optimization in debug builds of ANGLE.
Review URL: http://codereview.appspot.com/3945043
git-svn-id: https://angleproject.googlecode.com/svn/trunk@541 736b8ea6-26fd-11df-bfd4-992fa37f6226
A couple of things to note:
- This CL only validates the "form" of loop and indexing. It does not detect number-of-iterations or out-of-bound access. This will require more involved analysis/heuristics.
- I haved combined SH_VALIDATE_CONTROL_FLOW and SH_VALIDATE_INDEXING into one flag - SH_VALIDATE_LOOP_INDEXING. Validating both together is much easier.
BUG=48
Review URL: http://codereview.appspot.com/3225041
git-svn-id: https://angleproject.googlecode.com/svn/trunk@491 736b8ea6-26fd-11df-bfd4-992fa37f6226
Symbol table entries depend on three things - language, spec (not now but may eventually), and built-in resources.
We used to build two global symbol-tables - one for each language. During each compile, one of the symbol table was
copied and resource-specific stuff was added. I have moved the symbol table to TCompiler that gets initilized when
compiler is created and reused for each compile. This makes it much cleaner and extensible in case a spec requires
special entries to be added to the symbol table.
PS: Sorry for the long CL, but all of it needed to be done in one CL. I have verified that everything still compiles
and passes all conformance tests.
Review URL: http://codereview.appspot.com/1864044
git-svn-id: https://angleproject.googlecode.com/svn/trunk@351 736b8ea6-26fd-11df-bfd4-992fa37f6226
1. Added include/GLSLANG which includes compiler API
2. Deleted src/include and moved the header files to the same directory as the corresponding source files
3. Modied include path to be relative to src/. I have only fixed paths for files I moved. We should fix it for all new files at least. It is much easier to see where an included file is coming from.
I noticed that a few libGLESv2 source files include headers from libEGL project, which seems wrong. I think we should address this issue. Next step: move compiler source files to compiler/frontend and create two new projects compiler/glsl_backend and compiler/hlsl_backend.
Review URL: http://codereview.appspot.com/662042
git-svn-id: https://angleproject.googlecode.com/svn/trunk@62 736b8ea6-26fd-11df-bfd4-992fa37f6226
Jamie Madill
Olli Etuaho
Qiankun Miao
Corentin Wallez
Yuly Novikov
Zhenyao Mo
Qin Jiajia
Kenneth Russell
Shao
Geoff Lang
Martin Radev
Ian Ewell
Austin Kinross
Kimmo Kinnunen
Dmitry Skiba
Qingqing Deng
Daniel Bratell
Erik Dahlström
Shannon Woods
Nicolas Capens
Nicolas Capens
Jamie Madill
shannonwoods@chromium.org
shannon.woods%transgaming.com@gtempaccount.com
shannon.woods@transgaming.com
daniel@transgaming.com
gman@chromium.org
maxvujovic@gmail.com
apatrick@chromium.org
kbr@chromium.org
zmo@google.com
alokp@chromium.org