Chromium's Linux toolchain doesn't implement the return value of
std::vector::insert correctly, causing a build failure. Remove an
unnecessary assignment of the return value to fix this build regression.
The regression was caused by the commit:
"Put each array declarator into a separate declaration in HLSL output"
TEST=angle_unittests
Change-Id: I2959122d28e4c7e6d6a4d842a97a8f1fd4f27ca1
Reviewed-on: https://chromium-review.googlesource.com/266990
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
The internal flag disables decorating a given symbol in output, effectively
placing it to a different namespace than user-defined symbols. This enables the
compiler to insert symbols to the tree when transforming it to be suitable for
HLSL output without running into name conflicts. In this patch the flag is
separated from the qualifiers since sometimes different qualifiers need to be
used with these internal symbols.
TEST=angle_unittests, angle_end2end_tests, WebGL conformance tests
BUG=angleproject:941
Change-Id: I7036bed98fdb1478a383bb959ca03b42c3cb8100
Reviewed-on: https://chromium-review.googlesource.com/266690
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Do this by separating each array initialization into a declaration and an
assignment. Array assignment is already supported in HLSL output by replacing
it with a function call.
The functionality is tested by the struct array constructor tests in dEQP.
BUG=angleproject:941
TEST=dEQP-GLES3.functional.shaders.arrays.constructor.*
Change-Id: Ida84fc343b767bea8b2d04e91c60cb8197d39039
Reviewed-on: https://chromium-review.googlesource.com/266002
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Since HLSL doesn't support arrays as l-values, HLSL output needs to split
declarators that initialize arrays to variable declaration and assignment
implemented via a function call. To prepare for this, it is necessary that each
declarator has its own declaration.
BUG=angleproject:941
TEST=angle_end2end_tests, WebGL conformance tests
Change-Id: I43dee487578561c01dbde90c2f55a93dda2f057a
Reviewed-on: https://chromium-review.googlesource.com/266001
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
This change adds constant folding support for unary exponential
built-ins - exp, log, exp2, log2, sqrt and inversesqrt.
BUG=angleproject:913
TEST= dEQP tests
dEQP-GLES3.functional.shaders.constant_expressions.builtin_functions.exponential*
(48 out of 56 tests started passing with this change)
Change-Id: I4b98782c4c4b72dd7d60dfc4f18ba6961526ec41
Reviewed-on: https://chromium-review.googlesource.com/266797
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
In file included from ../../third_party/angle/src/libANGLE/Framebuffer.cpp:10:
In file included from ../../third_party/angle/src/libANGLE/Framebuffer.h:13:
In file included from /Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/vector:68:
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_construct.h:81:38: error: call to implicitly-deleted copy constructor of 'gl::FramebufferAttachment'
::new(static_cast<void*>(__p)) _T1(__value);
^ ~~~~~~~
This reverts commit 13773b26df.
Change-Id: If79f2797fe46798cbe5b39d83c9bcb1a7e87026d
Reviewed-on: https://chromium-review.googlesource.com/266643
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Compile errors on Mac:
In file included from ../../third_party/angle/src/libANGLE/Framebuffer.cpp:10:
In file included from ../../third_party/angle/src/libANGLE/Framebuffer.h:13:
In file included from /Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/vector:68:
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_construct.h:81:38: error: call to implicitly-deleted copy constructor of 'gl::FramebufferAttachment'
::new(static_cast<void*>(__p)) _T1(__value);
^ ~~~~~~~
This reverts commit ed61a5f673.
Change-Id: I602bffc96f77cffa217cb63a5cc3caf334fd9879
Reviewed-on: https://chromium-review.googlesource.com/266652
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
This makes "Data" a proper class, and enforces access control when
used in FramebufferImpl. This gives a cleaner refactor when we
switch the internals of the class to use value types to store
attachments instead of pointer types.
BUG=angleproject:963
Change-Id: If825095458eaf9367f616f0bb54084025efb9882
Reviewed-on: https://chromium-review.googlesource.com/265937
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
This should give us a bound on how much we can improve startup
time in ANGLE on D3D11 across all users.
BUG=angleproject:944
BUG=436191
Change-Id: Ie9047c0424429aecec5f6d7be8e119ebcc53fbe3
Reviewed-on: https://chromium-review.googlesource.com/266524
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
The dashboard automatically marks 'frames' as 'lower is better', while
'score' is automatically marked as 'higher is better'. Hence, use
score instead of frames.
BUG=468852
Change-Id: I02b3a9e4b74989793d4bfbf21a94e43670b3e028
Reviewed-on: https://chromium-review.googlesource.com/266522
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Move validation of sample counts into the Renderbuffer implementations
because the exact supported sample counts are not always known.
BUG=angleoproject:886
Change-Id: I9c90d9d435e940b852343a29a6aa11d6cb1ad23b
Reviewed-on: https://chromium-review.googlesource.com/255513
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
The Windows helper function HRESULT_CODE masks out some bits that
obscure the error code. This could be why we're seeing some
undetermined errors in our logs.
BUG=477701
Change-Id: I6eee442c149c2568e3823edc538d365b06ee20d8
Reviewed-on: https://chromium-review.googlesource.com/266375
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
This change adds constant folding support for unary common built-ins:
abs, sign, floor, trunc, round, roundEven, ceil and fract.
BUG=angleproject:913
TEST= dEQP tests
dEQP-GLES3.functional.shaders.constant_expressions.builtin_functions.common*
(80 out of 210 tests started passing with this change)
Change-Id: I46312fec43084601d4fca8195ddaaa5292f1c02a
Reviewed-on: https://chromium-review.googlesource.com/265967
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Our data shows the most common D3D11CreateDevice failure as being
'other error'. Explicitly enumerate more error codes so we can
figure out which value we're getting.
BUG=47701
Change-Id: Ibcda5e8ff1bb0368b1bfe3c8e7e3ffbb404771ce
Reviewed-on: https://chromium-review.googlesource.com/265939
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
ProgramGL was unable to handle uniform arrays and improperly set uniform
locations. It now queries the driver for the location of each uniform and
iterates over all array elements.
BUG=angleproject:882
Change-Id: Iffe9d12944b2399f19f4a7823df2f535a430d6e3
Reviewed-on: https://chromium-review.googlesource.com/265724
Tested-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
This change adds constant folding support for unary exponential
built-ins - exp, log, exp2, log2, sqrt and inversesqrt.
BUG=angleproject:913
TEST= dEQP tests
dEQP-GLES3.functional.shaders.constant_expressions.builtin_functions.exponential*
(48 out of 56 tests started passing with this change)
Change-Id: I63133ee8c04c4a8d6cb30da5788e9227c05d4cbe
Reviewed-on: https://chromium-review.googlesource.com/266071
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
This change adds constant folding support for trigonometry built-in
functions. Constant folding for these functions also fixes constant
expression issues where constant initializer is a built-in trignometry
function whose arguments are all constant expressions.
BUG=angleproject:913
TEST= dEQP tests
dEQP-GLES3.functional.shaders.constant_expressions.builtin_functions.angle_and_trigonometry*
(112 out of 120 tests pass with this change)
Change-Id: I2b7a61320819dcd095827faa1fd16e835f4688b4
Reviewed-on: https://chromium-review.googlesource.com/265819
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
"entry" is an old C keyword, so it's better not to use it as a variable name.
Also fix a few other minor style issues in the code.
TEST=angle_unittests
BUG=angleproject:941
Change-Id: I59470555227985262b3e914ff6ca11e88d15fd8c
Reviewed-on: https://chromium-review.googlesource.com/265647
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
This microbenchmark tests the time at which we find index ranges
in the cache, and how long the call to prepareIndexData might take.
It also verifies we successfully store index ranges in the cache.
BUG=angleproject:956
Change-Id: I0f1b0c00daa73d8e1bcde197d9de80ca229078b7
Reviewed-on: https://chromium-review.googlesource.com/262779
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Support expressions where the expression that .length() is called on
does not have side effects.
Tested with WebGL 2 test sdk/tests/deqp/data/gles3/shaders/arrays.html
TEST=WebGL 2 conformance tests
BUG=angleproject:972
Change-Id: Ib4f8377a51da61179b6e47fbcf6b4d915e351fbd
Reviewed-on: https://chromium-review.googlesource.com/265654
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
ESSL specs only allow a limited number of operators on arrays and
structs. The spec section on the ternary operator contradicts this to an
extent, saying that the second and third operands can be "any type" or
"any type other than an array", but we interpret the spec so that the
operator restrictions on structures and arrays override this.
BUG=angleproject:976
TEST=angle_unittests
Change-Id: Icd90d5450dcb94bb23b1683d4cb9e579e82de4ad
Reviewed-on: https://chromium-review.googlesource.com/265644
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Refactor ternary operator parsing so that validation is done in
ParseContext and Intermediate's role is simply to create the node added
to the tree.
Remove partially bugged checks for null nodes as a part of this - in
error cases the parser doesn't typically add null nodes to the tree, but
rather always has a fallback to add a dummy node if parsing fails as a
method of recovery. When parsing ternary operators it should be
guaranteed that none of the parameter nodes is null.
Includes a better explanation of why ternary operators are not always
folded when only the condition is constant, and a test to make sure this
doesn't regress.
BUG=angleproject:952
TEST=WebGL conformance tests, angle_unittests
Change-Id: Icbcb721b5ab36cf314a16e79f9814aef1f355fa0
Reviewed-on: https://chromium-review.googlesource.com/265643
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
We would rewrite our index data every draw call. Change the index
check to see if we're writing to the same sized / typed static
buffer and only rewrite the data if the user re-uploaded.
Also add a performance test for the primitive restart workaround.
As a future improvement we could avoid creating new D3D objects
every time we reinitialize static data, since BufferSubData
calls don't change the size of the buffer if the index type
remains the same.
BUG=476658
Change-Id: I9d2540ad8b1b34fa0142ba0bf794cf572da8c61d
Reviewed-on: https://chromium-review.googlesource.com/265838
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
We still were using the old cassert code, with a boolean return
value on our initialization code. We can make use of the gtest
macros and helpers to check for a successful init or GL errors.
BUG=476658
Change-Id: I09cbb3d40748cbeaf530ae8f23fb8a1b07e7611f
Reviewed-on: https://chromium-review.googlesource.com/265837
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
We can store all relevant information in the base class, which
lets us avoid using any virtual methods. This will finally let
us avoid using reallocations on FBO attachment sets.
BUG=angleproject:963
Change-Id: Ib4b61da14efaf843478b059499c01e34f9c65e4f
Reviewed-on: https://chromium-review.googlesource.com/263488
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
This lets us share objects (Textures/RBs/Surface) in the attachment
class. It will let us squash the attachment classes into one type,
which will in turn let us store them by-value, instead of by-pointer.
BUG=angleproject:963
Change-Id: Ia9a43dbc3b99475c00f6bc2ed5475deef55addc3
Reviewed-on: https://chromium-review.googlesource.com/263487
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
ESSL3 introduces implicit array size that is determined automatically
according to the initializer. Implicit sizes are resolved when parsing
constructors and when initializers are evaluated, so ANGLE's AST will not
contain implicit sizes.
Declarations where there are two differently sized arrays with the same
implicitly sized type, for example:
float[] a = float[](0.0), b = float[](0.0, 1.0);
will be transformed into declarations where the two arrays don't share
the array size like this:
float a[1] = float[1](0.0), float b[2] = float[2](0.0, 1.0);
so they are not a problem.
Unlike sized arrays, implicitly sized arrays don't have a size limit
enforced by the parser.
Include a test that verifies that non-initialization of an implicitly
sized array defined using ESSL3 type syntax is caught by the parser.
Additionally tested with WebGL 2 test
sdk/tests/deqp/data/gles3/shaders/arrays.html
TEST=WebGL 2 conformance tests, angle_unittests
BUG=angleproject:941
Change-Id: Ib55b7601848102a103af9db284a80f09abaeb021
Reviewed-on: https://chromium-review.googlesource.com/265653
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Still missing from this patch: HLSL output, implicitly sized arrays.
Tested with WebGL 2 test sdk/tests/deqp/data/gles3/shaders/arrays.html
TEST=WebGL 2 conformance tests
BUG=angleproject:941
Change-Id: I900f2af843fd8046f23dd4b77352e77026bbba84
Reviewed-on: https://chromium-review.googlesource.com/265652
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Remove the unused identifierSymbol parameter from parseSingleDeclarator
and unify the ordering of parameters and the code style of different
declaration and declarator parsing functions. Some minor functional
changes to array size handling are done mainly to unify error message
generation. There's soon going to be more of these functions, so it's
good to be systematic.
TEST=angle_unittests, WebGL conformance tests
BUG=angleproject:941
Change-Id: I03b0220de93ca5719fdb7c1790a5999b8cb5b225
Reviewed-on: https://chromium-review.googlesource.com/265202
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
