The translator gl::Varying struct does not need to know about register
allocation. We can put that entirely in the API library. This makes
exposing Varying variables with the new translator types cleaner.
BUG=angle:466
Change-Id: Ib85ac27de003913a01f76d5f4dc52454530859e6
Reviewed-on: https://chromium-review.googlesource.com/199736
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
We only assigned to elementIndex, and never referenced the value
at any point in our code.
BUG=angle:466
Change-Id: I541a353110bcd1863b07b21bcf21fad38be19ca1
Reviewed-on: https://chromium-review.googlesource.com/199735
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
I came across these three classes in the last CL, so do some
cleanup as I touched these classes.
BUG=
TEST=webgl conformance, no regressions
Change-Id: I2819bab5965fcb4917f85c2eded571a7f95ab9a2
Reviewed-on: https://chromium-review.googlesource.com/199423
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Zhenyao Mo <zmo@chromium.org>
Basically we should be able to reuse a struct name once the previous
use is out of the scope, or we can reuse it if we are in a inner scope
than where it is defined before.
BUG=368910
BUG=angle:618
TEST=conformance/glsl/bugs/nested-structs-with-same-name.html
Change-Id: Icfac76b844deaca0c8a0501d7426ff3802e657dc
Reviewed-on: https://chromium-review.googlesource.com/199137
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Zhenyao Mo <zmo@chromium.org>
Loading program binaries across different architectures would cause
runtime errors due to use of size_t.
Also fix the ANGLE major and minor version that were clobbered in an
earlier commit.
BUG=angle:647
BUG=371435
Change-Id: If2ad4c8fc246cc9ff0b4d95ba87b7d1ed109a064
Reviewed-on: https://chromium-review.googlesource.com/199102
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Some shaders fail to compile with validation error messages that make no sense.
BUG=angle:648,chromium:372016
Change-Id: Ief0e28efa6bc7eaa483c95f45c00ce4f9f20e541
Reviewed-on: https://chromium-review.googlesource.com/199311
Tested-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
We were not taking the state of GL_POLYGON_OFFSET_FILL into account.
BUG=371604
Change-Id: I9b490ed043faeece86665acaef0b865bf1f7b60d
Reviewed-on: https://chromium-review.googlesource.com/199121
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Nicolas Capens <nicolascapens@chromium.org>
If there are only buffers with data revision 0, getLatestStorage will skip
over them. Fixed the if statement so that it will always find a buffer if
one exists.
BUG=angle:644
Change-Id: I24fc426383c9ae18b7ccf2f8937a9daa7a071ebe
Reviewed-on: https://chromium-review.googlesource.com/198826
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
Full support for using pack buffers as vertex buffers or other
binding points requires us to copy through the staging buffer.
BUG=angle:511
Change-Id: Ife0f5390a1a83dfbe0fa0b19db72f3a8b82b6b83
Reviewed-on: https://chromium-review.googlesource.com/198435
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Pack buffers used in different binding points when combined
with other buffer operations require us to be able to read
from the pack buffer then write to the native buffer.
BUG=angle:511
Change-Id: I2e859695235eb649ddd5dfc1332ecb19b57c1933
Reviewed-on: https://chromium-review.googlesource.com/198434
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
With our fix to huge buffer allocations, an extra check was preventing
pixel pack from running on the first try.
BUG=angle:511
Change-Id: Idabafe4e204ad3b7bf2010595dc455affe93dae0
Reviewed-on: https://chromium-review.googlesource.com/198825
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Making the contructors for shader variables inline saves us from
exporting them across DLL boundaries. This makes it easier to use
them in the translator when building the translator as a DLL.
BUG=angle:466
Change-Id: Iee0556e06dc1f9e98fe9eea6577819305de0dd0b
Reviewed-on: https://chromium-review.googlesource.com/198555
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Since we incur some kind of type confusion that stops us from properly
catching bad_alloc exceptions generated when compiled with exceptions
or when ANGLE is compiled with C++ exceptions, use catch-all clauses.
BUG=angle:634
Change-Id: I6d6efbf1fc7a4ebf8f13150b2814bfcd5edaad91
Reviewed-on: https://chromium-review.googlesource.com/198421
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
When we would allocate huge buffers, we would not always gracefully
fail and return a GL error back to the application. We should be able
to better handle buffer allocation failures with this patch.
BUG=angle:634
Change-Id: Ic3edce6d22b731ec52666a2a0e82f9a4fbbb23ae
Reviewed-on: https://chromium-review.googlesource.com/197994
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
The pack pixels operation is split in two halves: a GPU
copy then a CPU readback. We defer the CPU readback until
we can't wait any longer. That is, we do the readback when
the user maps the buffer, or there's another readback or
internal operation.
This offers the benefits of doing as much GPU work as
asynchronously as possible, and only doing the readback
work on related API calls (map or subsequent pack calls).
BUG=angle:511
Change-Id: I95a01da2b0e842438b180e8cdbb382c9a46ae210
Reviewed-on: https://chromium-review.googlesource.com/197836
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
We would generate multiple vertex binaries that result in the same
HLSL code, eg for vec2 and vec3 vertex attributes. Eliminate
duplicates by using the converted attribute type for testing
for matching binaries.
BUG=angle:599
Change-Id: I061588164577ff9fa69ebb7d8a3f2bf6bb6fe013
Reviewed-on: https://chromium-review.googlesource.com/197830
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
It seems we weren't catching bad_alloc despite using the correct syntax.
Using ellipses solves the problem, and since we only expect bad_alloc
it does the equivalent result of catching and returning out of memory.
I'm currently not aware of the proper syntax to catch bad_alloc.
BUg=angle:634
Change-Id: Ib3154546d1b72d180cb565c71f35716696863cdd
Reviewed-on: https://chromium-review.googlesource.com/198245
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Keeping a persistent storage allows us to treat the memory
buffer as the canonical copy of the pack buffer data, and
simplifies corner cases.
BUG=angle:511
Change-Id: Ied4dcb2edce2b85f68645f5a65603cbf18ad5a16
Reviewed-on: https://chromium-review.googlesource.com/197701
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Update the BufferStorage classes to use size_t for all sizes and offsets.
BufferStorage9 now uses a std::vector to manage its memory.
BUG=angle:631
Change-Id: Iea4e7b33ede59a5b9c6a1245690c4b7865096fc3
Reviewed-on: https://chromium-review.googlesource.com/197819
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
Any time the git index changes, we will re-run the commit id hook.
This will ensure we never are left with stale commit ids from
other git commits.
BUG=angle:626
Change-Id: I03c37225fb902b6c1801e8f993d767122e8bfeb6
Reviewed-on: https://chromium-review.googlesource.com/197723
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
The generic alignment and conversion test to check for the possibility of using
direct storage is relatively expensive. Float types can be tested more quickly.
BUG=angle:613
Change-Id: I5ab008ce82c8b652f0392c20a80a5b198b2437a5
Reviewed-on: https://chromium-review.googlesource.com/197721
Tested-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Several small build errors present on Linux cropped up due to
different warning flags and platform quirks.
BUG=angle:627
Change-Id: If8f651cacf05bb06ecb129be47b12729ccc3f69b
Reviewed-on: https://chromium-review.googlesource.com/197724
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
"Refactor BufferStorage11" caused a performance regression by dropping the line
which sets mReadUsageCount to 0. This causes markBufferUsage() to clear mResovedData
which then has to be restored on the next getData() call.
BUG=angle:613
Change-Id: I61c4b4960305a69b315c20ced66265a770002338
Reviewed-on: https://chromium-review.googlesource.com/197503
Tested-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
CompressedTexSubImage would disallow 1x1 or 2x2 mips being set for any mip
level except 0. This made it impossible to set the data in the lowest mip
levels.
BUG=angle:623
Change-Id: I623414ae4fd5d6b051579285160296b03fd36486
Reviewed-on: https://chromium-review.googlesource.com/197250
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
(cherry picked from commit cc84a853eb)
Reviewed-on: https://chromium-review.googlesource.com/197654
We had neglected to reference scope bracket values when
initially constructing the scoped struct name. Fixes the
new WebGL test.
BUG=angle:618
Change-Id: Ie78a8264c9e16c5a6574cecd662adbd5475d6495
Reviewed-on: https://chromium-review.googlesource.com/197252
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Only creating the staging buffer on use saves us from allocating
a D3D11 staging buffer for pack buffers. This saves some memory
and time when we're only using a buffer object for asynchronous
readback.
BUG=angle:511
Change-Id: I97b37cc27aba4a4526025815b5935b9e74abae2e
Reviewed-on: https://chromium-review.googlesource.com/195367
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
(cherry picked from commit ebf396c1dd)
Reviewed-on: https://chromium-review.googlesource.com/197281
Internally pack buffers are CPU pointers, with an associated
staging texture. In the map call we copy the data out of the
staging memory to CPU memory, and return a pointer to the CPU
buffer.
BUG=angle:511
Change-Id: I2a82addd2f21241d8d49554b2fc71d890a166386
Reviewed-on: https://chromium-review.googlesource.com/195366
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
(cherry picked from commit 0b44a455b5)
Reviewed-on: https://chromium-review.googlesource.com/197272
With this change, the common sources shared between translator
and translator_static are compiled in a static library. There
is only one file with exported functions which needs to be
compiled for each target. This should reduce ANGLE and chromium
build times.
BUG=angle:569
Change-Id: I3ce011872323ec988befbd6db731add4fce5787b
Reviewed-on: https://chromium-review.googlesource.com/197271
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill
Geoff Lang
Zhenyao Mo
Nicolas Capens
Shannon Woods