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>
The check should be using the newer operator== to check if attachments
are the same - the id() method will hit an UNREACHABLE if it's called
on a Surface attachment.
I noticed this when using this method in the Vulkan RenderPass
implementation.
BUG=angleproject:1583
Change-Id: I387b35805893d04003b22a1c7c9c12fc41c726ce
Reviewed-on: https://chromium-review.googlesource.com/412801
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@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>
This fixes parsing floats that are out-of-range, and floats that have
more digits than the standard library float parsing functions can
handle. In these cases, we now fall back to a custom implementation of
float parsing. The custom parsing path can correctly process floats
with up to hundreds of millions of digits in their mantissa part.
Rounding behavior of the custom float parser may not be entirely
consistent with the standard parser, but the error should be at most
a few ULP. This can be considered acceptable since floating point
operations are not expected to be exact in GLSL in general. Settling
for lower accuracy also enables the parser to run in constant memory,
instead of having to store all the significant digits of the decimal
mantissa being parsed.
BUG=angleproject:1613
TEST=angle_unittests
Change-Id: I04a5d9ae5aaca48ef14b79cca5b997078614eb1c
Reviewed-on: https://chromium-review.googlesource.com/412082
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Use it to implement lazy state setting methods for texture filters and
swizzle that will be used in subsequent workarounds.
BUG=angleproject:1356
Change-Id: Ia58267c4f125262cf57fbd98438a6d8eb8a04b33
Reviewed-on: https://chromium-review.googlesource.com/412404
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@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>
The comment here was incorrect, and the signature passed some
redundant arguments.
Noticed this when I was looking at the code for Vulkan/glslang.
BUG=angleproject:1576
Change-Id: Ie9e7eb7cbe4b65503901b2550e95cd818b7c28c0
Reviewed-on: https://chromium-review.googlesource.com/412324
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
The missing check was a bit buggy, and the paths were not updated
to the new 'gyp' folder instead of 'build'.
BUG=angleproject:1569
Change-Id: I10408252851e90b79e306c8aea175ebe6a931b61
Reviewed-on: https://chromium-review.googlesource.com/412320
Reviewed-by: Geoff Lang <geofflang@chromium.org>
This workaround avoids using inter-buffer copies involving constant
buffers. Instead of copying from a staging storage to a constant
buffer (or vice-versa), the Buffer memory managment will keep the
system memory storage around permanently. This uses a bit more memory
but should fix all the problematic cases where we have the canonical
version of the buffer data inside GPU memory.
BUG=chromium:593024
Change-Id: I2ce0cfd22784aa43e819ce2df2d0da540d0a0cfe
Reviewed-on: https://chromium-review.googlesource.com/412140
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
We can call setData internally to re-use the same code.
BUG=chromium:593024
Change-Id: I9f53bef1e86a11fc23799123937c354bf45de014
Reviewed-on: https://chromium-review.googlesource.com/411919
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
This getter will now return the offset to bind along with the
ID3D11Buffer pointer. This encapsulates the logic of the emulation
so that we only actually check the capabilities of the driver in
a single place. This solves the issue of needing to edit the code
in multiple places when trying to force the caps for debugging,
and also encapsulates the offset calculation in the Buffer11 class.
BUG=chromium:593024
Change-Id: Idb09d560868ae12b98bcaf4ea031c4e0b6c82b4a
Reviewed-on: https://chromium-review.googlesource.com/411918
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
The old 'build' dir was copying stale DLLs.
BUG=angleproject:1569
Change-Id: Ib11fb9f1e1e480fe32af3f291357e0fb92429318
Reviewed-on: https://chromium-review.googlesource.com/411389
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
The OpenGL spec allows "count" to overflow safely implemented but some
drivers like the Intel Windows OpenGL driver don't handle this
correctly and crash on overflow tests.
BUG=661413
Change-Id: I10de9292c75daa375f002850900bb5e1cbfce3b6
Reviewed-on: https://chromium-review.googlesource.com/411387
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reland with a Windows build fix.
We want to move the Chromium initialization of the ANGLE platform from
being Windows-specific to being EGL-specific. Because the mechanisms by
which the ANGLE library is loaded are OS-specific, it is inconvenient to
use dlsym and friends to get the ANGLEPlatform entry points. Instead
we expose the through eglGetProcAddress which is readily available in the
EGL-specific part of Chromium.
BUG=angleproject:1621
Change-Id: I022a39493756a3b5d1ed626fd05e74af3f043211
Reviewed-on: https://chromium-review.googlesource.com/410066
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Before validating the texture format, verify that the texture level already
exists in glTexSubImage calls.
BUG=602737
Change-Id: I0d83c7d43c7b358abdb59583dc83265df70c13b5
Reviewed-on: https://chromium-review.googlesource.com/411361
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This simplifies the error handling code, and allows the use of the
ANGLE_TRY macro (and friends).
BUG=angleproject:1576
Change-Id: I3142388b10d0dd67a7f49a5c8c3d11102996be93
Reviewed-on: https://chromium-review.googlesource.com/411201
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
The SRGB blit workaround had to wrong assumptions:
- SRGB blits can have a multisample source.
- The woarkound is needed even when the filter is GL_LINEAR in the
case where we are doing a RGB -> SRGB or RGB -> SRGB blit.
BUG=angleproject:1492
BUG=chromium:658898
Change-Id: I1d89572565a4e23c1c97bdf985bb21a445e898b7
Reviewed-on: https://chromium-review.googlesource.com/409540
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Produces a build warning in standalone, might require build file updates:
> locally defined symbol ANGLEPlatformInitialize imported in function <snip>
At least in GYP, libEGL does not have LIBANGLE_IMPLEMENTATION defined, so it defines this API with __declspec(dllimport), which is incorrect, since the function is local to the module. We should fix the layering and/or export defs.
BUG=angleproject:1621
This reverts commit 0504fcc17a.
Change-Id: Ida67db69eb64e4a8f2c13dcf129d40b332f2da9d
Reviewed-on: https://chromium-review.googlesource.com/410065
Reviewed-by: Jamie Madill <jmadill@chromium.org>
We want to move the Chromium initialization of the ANGLE platform from
being Windows-specific to being EGL-specific. Because the mechanisms by
which the ANGLE library is loaded are OS-specific, it is inconvenient to
use dlsym and friends to get the ANGLEPlatform entry points. Instead
we expose the through eglGetProcAddress which is readily available in the
EGL-specific part of Chromium.
BUG=angleproject:1621
Change-Id: I7adbea003103d0331ec9eece7b881e27bd6b1a5d
Reviewed-on: https://chromium-review.googlesource.com/410063
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
The patch adds support for the three remaining memory qualifiers:
volatile, coherent and restrict.
BUG=angleproject:1442
TEST=angle_unittests
TEST=angle_end2end_tests
Change-Id: Ie662d304af2399468df1d976e04c38dada1e2cec
Reviewed-on: https://chromium-review.googlesource.com/385876
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Instead of having separate GetGlobal* functions, interact with the global
objects through a single Thread object. This reduces the number of TLS
lookups in many EGL functions and allows the Thread object to be passed
down to other objects if needed.
BUG=angleproject:1618
Change-Id: I1f9a89e8899d637633f4e91fda0e38ac308dd020
Reviewed-on: https://chromium-review.googlesource.com/409637
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
The failure is due to when we initialize variables to 0, we re-create
the struct TType, and it contains a different unique id from the
original struct TType, thus leading to a different hashed name.
BUG=chromium:641129
TEST=webgl_conformance,webgl2_conformance
Change-Id: I267b97fa496f55ea59dacee93af8f6a90f3e66cb
Reviewed-on: https://chromium-review.googlesource.com/409602
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
In RendererD3D::createRenderTarget, we use getNearestSamples(samples)'s
result to assign D3D11_TEXTURE2D_DESC.SampleDesc.Count. However, in
renderer11::updateState, we used the original samples to calculate mask
by GetBlendSampleMask not the supported nearest samples. It would result
that multisample rendering result was incorrect when enable
AMPLE_COVERAGE and the samples is not in the suported list but less than
max samples. At least, on Intel Win platform, we can reproduce it.
The fixing is to use same samples in these two places.
BUG=angleproject:1610
TEST=MultisampleCompatibilityTest.DrawCoverageAndResolve
Change-Id: I255b12d1032317145adfcee94e65e88ae5307113
Reviewed-on: https://chromium-review.googlesource.com/408516
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@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>
He Yunchao
Geoff Lang
Jamie Madill
Olli Etuaho
Corentin Wallez
Qiankun Miao
Yuly Novikov
Bryan Bernhart
Zhenyao Mo
Martin Radev
Qin Jiajia