This avoids the need to consult the resource maps twice per bind.
It improves performance in applications which call Bind* often.
BUG=angleproject:1333
Change-Id: I7b733cc89e50e24a2e38a2eb2dc7fd658d612e27
Reviewed-on: https://chromium-review.googlesource.com/331386
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Translated attributes are now stored in the VertexArray11 in a cache,
and only updated when dirty bits change. Currently dynamic attributes
must be re-translated every call, so these are stored in a list and
processed repeatedly.
This skips doing a lot of the VertexDataManager work for vertex
attributes that don't change between draw calls.
Current value attributes, which correspond to disabled attributes that
the program will pulls vertex data from, are owned by the Context, so
these need to be handled outside of the VertexArray11.
Further changes will be necessary to reduce the redundant work we do in
the InputLayoutCache. We shouldn't need to re-check the cache if
nothing relevant changed.
This give about a 23% performance improvement on the draw call
benchmark on my machine.
BUG=angleproject:1327
Change-Id: I7fb944d32ea7e6c78b9e478406bdb7e10a7fc05b
Reviewed-on: https://chromium-review.googlesource.com/330173
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
GL_OES_depth32 is required for DEPTH_COMPONENT32_OES render buffers.
This stops Mesa from complaining when using GLES in the back end.
BUG=angleproject:1301
Change-Id: I8c6ce6a5ce0cb5bf26157e3bb414f391a41d15c4
Reviewed-on: https://chromium-review.googlesource.com/331359
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Frank Henigman <fjhenigman@chromium.org>
The mCounter field became exposed as unused after it was initialied in
the constructor initializer list. Previously this was hidden because
it was initialized in the body of the constructor.
BUG=angleproject:1327
Change-Id: I18d9aa8a377d234f4c161ace845edfb9fc7f226c
Reviewed-on: https://chromium-review.googlesource.com/331385
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Instead of querying DXGI format info to determine whether framebuffer
data can be copied to packPixels target memory with memcpy, compare
the internal format information from the ANGLE format to the packing
format. This makes it possible to change some of the DXGI formats
used for integer textures without breaking packPixels.
This makes it possible to entirely remove the DXGI format to GL
internal format mapping from the DXGI format info table.
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.fbo.* (no regressions),
dEQP-GLES3.functional.pbo.* (no regressions),
Change-Id: Id5ffd581349e7afe39872d69cb05381f3e78d352
Reviewed-on: https://chromium-review.googlesource.com/329214
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Extend the info log length checks to shader_utils used by tests, and
treat info log with length 1 as empty, since it can only include the
null terminator. At least the Intel GL driver may generate "\0" as
info log in some situations, for example when compiling a user-defined
function with 50000 parameters.
BUG=angleproject:1323
Change-Id: I00f2965539ec235cb949c80c2a9e1d063d32fa15
Reviewed-on: https://chromium-review.googlesource.com/331461
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This stops Mesa from complaining when using GLES in the back end.
BUG=angleproject:1301
Change-Id: I0b8cb78efea97c1ea0d21cd6b9f656e53b9b6cc2
Reviewed-on: https://chromium-review.googlesource.com/331395
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Frank Henigman <fjhenigman@chromium.org>
This is done to make it possible to change some of the DXGI formats
of integer textures without affecting their color read function
associations.
The packPixels function gets the ANGLE format from the texture helper,
which now requires the ANGLE format to be passed in at the time of
creation.
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.fbo.* (no regressions),
dEQP-GLES3.functional.pbo.* (all pass)
Change-Id: I368337cfe5f8c86ff3292009ccf29e9d01409a07
Reviewed-on: https://chromium-review.googlesource.com/329213
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
D3D compiler can't resolve between these overloaded functions:
float4 vec4(float2x2 x0);
float4 vec4(float4 x0);
Include the parameter types in the function name to disambiguate
between overloaded user-defined functions and constructors, like this:
float4 vec4_float2x2(float2x2 x0);
float4 vec4_float4(float4 x0);
This is only done for float2x2 and float4 parameters, other parameter
types like float2x3 vs. float3x2 don't need this.
BUG=angleproject:1099
BUG=angleproject:1030
TEST=angle_end2end_tests,
dEQP-GLES3.functional.attribute_location.* (10 more tests pass),
dEQP-GLES2.functional.attribute_location.*
Change-Id: Ief047d41b0adbc238393c3c13cb29771cbb83d58
Reviewed-on: https://chromium-review.googlesource.com/329882
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
We previously marked them as failing but they are causing a crash so we
skip them until they are fixed.
BUG=angleproject:1323
Change-Id: I717e402d56ea88ef93da50d10803d0a62aa58fdf
Reviewed-on: https://chromium-review.googlesource.com/331281
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This change does a couple things. First, it uses the 'active attribs'
mask in the gl::Program to sort the translated attributes, instead of
checking the translated attribute themselves. This means we don't have
to consult the 'active' field of the translated attributes, which in
turns means we don't have to update the active field in the attributes,
which breaks the dependency of the attributes on the gl::Program.
Second, use a dynamically sized array for storing the cached vertex
attributes in the InputLayoutCache. This is nice because it means
we don't have to store the size of the array separately.
Also some other refactoring cleanups. Refactoring change only.
BUG=angleproject:1327
Change-Id: Iab22de92840b30674b92eca72e450673ed9f6d6d
Reviewed-on: https://chromium-review.googlesource.com/330172
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
These were only referenced by the StateManager11. Instead of using
these cache variables, ensure the StateManager11 marks the RT as
dirty and apply the RenderTarget state.
Also remove the RenderTarget setters from Renderer11, and don't
unapply RTs after a one-time set operation. The StateManager11
should take care of updating the necessary changes itself.
BUG=angleproject:1321
Change-Id: Idc8d22ea9e92ac8d07392ab10d067df6084403bb
Reviewed-on: https://chromium-review.googlesource.com/330462
Reviewed-by: John Bauman <jbauman@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This will make it easier to verify changes to integer texture DXGI
formats. Currently the DXGI format info table contains some values
that wouldn't make sense after the integer formats are changed, such
as R32_TYPELESS being recorded as a depth format, and we need to make
sure no code relies on this kind of information to make changing the
table safe.
Includes cleaning up unused depth/stencil offset fields from
DXGIFormatInfo.
BUG=angleproject:1244
TEST=dEQP-GLES3.functional.fbo.blit.*depth*
Change-Id: I0149f28e4c6f961af99ac2f5a656f3fbfe13aee6
Reviewed-on: https://chromium-review.googlesource.com/328964
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
The count should be the total amount of shader ids written. Before
this patch the code used to write the amount of attached shaders
to count regardless of the value of maxCount.
BUG=angleproject:1101
TEST=dEQP-GLES3.functional.state_query.shader.*
Change-Id: I5ae729748c7809f03fd496c927a76f60398d2b42
Reviewed-on: https://chromium-review.googlesource.com/329865
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Instead of splitting attributes into 'active enabled' and 'active
disabled', split them into static/dynamic/direct/current value, and
handle each group invidually. This also will allow the dirty bits
code to call in to the VertexDataManager separately for each type
of necessary vertex data translation, and skip it entirely for
direct buffer storage.
Should be a refactoring patch only.
BUG=angleproject:1327
Change-Id: I53cb5672054d99ae68e9aa2e5a3c046a002e360d
Reviewed-on: https://chromium-review.googlesource.com/330171
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
The current caching logic stores multiple static attributes in a single
buffer if the attributes share a D3D buffer - sometimes.
If a buffer is 'committed' (has been used in a draw) then we would
make a new D3D buffer for the next set of static attributes.
Instead use a simpler scheme of a single D3D buffer for each
static attribute. Also change rx::VertexBuffer to a reference
counted class. This simplifies the caching logic for static vertex
buffers (translated attributes) considerably. We only need to
release the buffers when the ref count is zero, and ensure we
track the ref count correctly when bound to D3D.
This leads the way towards using a simpler dirty bit scheme for
intelligent state updates, and less overhead doing work with
buffer state updates.
BUG=angleproject:1327
Change-Id: I99461d50b9663024eaa654cd56b42a63f1416d08
Reviewed-on: https://chromium-review.googlesource.com/330170
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
The new header contains EGL_NV_stream_consumer_gltexture_yuv, which will
be implemented in the future for video rendering purposes.
BUG=angleproject:1332
Change-Id: Ia35ee7360b8f09703ad2800c641c67f0f243e927
Reviewed-on: https://chromium-review.googlesource.com/330278
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Ian Ewell <ewell@google.com>
The GL driver can sometimes have an empty info log and return an info
log length of 0. This would cause a vector to be initialized with a
length of 0 just before it's .data() pointer was used, causing a
segfault.
BUG=angleproject:1323
Change-Id: Iaf9b569ec64a90c714a213562e427fb7cc8daa6b
Reviewed-on: https://chromium-review.googlesource.com/330197
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This is done to make it possible to change some of the DXGI formats
of integer textures without affecting their mip generation function
associations.
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.texture.mipmap.*generate* (all pass)
Change-Id: Ie83dd0e1883e9d8e267fbd4bf54b1e466fb0b210
Reviewed-on: https://chromium-review.googlesource.com/328963
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
This query would return either the RTV format, the DSV format or the
texture format depending on the render target. This made the code hard
to understand.
getDXGIFormat() calls are replaced by querying the ANGLE format, and
explicitly choosing which associated DXGI format to query info for
(RTV format or DSV format).
This refactoring makes changing some format associations for integer
texture formats easier in the future.
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.fbo.blit.* (no regressions)
Change-Id: Ibe3c03fc6b7768af1a131d4df3909a1e20a71228
Reviewed-on: https://chromium-review.googlesource.com/329102
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Add a corresponding GL internal format to ANGLE format set. This is
one step on the way to removing the problematic DXGI format to GL
format mapping. This will also make it possible to stop storing the
DXGIFormat field in RenderTarget11. The DXGIFormat field in
RenderTarget11 can currently carry either the DSV format, the RTV
format or the texture storage format of the resource it is managing,
which makes code using it hard to understand.
Also fills in missing componentType for some compressed ANGLE formats
in texture_format_data.json.
BUG=angleproject:1244
TEST=angle_end2end_tests
Change-Id: I87eedca8736aeface3fa6a0ec3c9d355cf006b24
Reviewed-on: https://chromium-review.googlesource.com/328961
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
The swizzle or copy shader needs to be chosen according to the
component type of the source SRV. Before this patch, the component
type was obtained by going through the mapping from the SRV DXGI
formats to GL formats.
This mapping is problematic, because it has entries that don't really
make sense, like R16_UNORM and R16_TYPELESS formats being mapped to
GL_DEPTH_COMPONENT16. This is an issue particularly because these
formats will be used for integer RED textures in the future. For
this reason the mapping should be removed.
In the case addressed by this specific commit, rather than look up the
component type of the SRV indirectly through the GL format table using
the GL internal format that corresponds to the DXGI format, just use
the component type of the DXGI format. The depth+stencil swizzle cases
where the component type is not well defined are handled as a special
case.
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.texture.swizzle.* (all pass),
dEQP-GLES3.functional.fbo.blit.* (no regressions)
Change-Id: I39fb8a14921b89d299e0077b3bea8b4e66ef218d
Reviewed-on: https://chromium-review.googlesource.com/329103
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
This formats were mistakenly listed as having no conversion necessary
in the vertex formats table. Fix is to mark them as CPU-converted.
This bug would only occur for 'direct' storage attributes, not those
that were dynamically streamed.
BUG=angleproject:1331
Change-Id: Ifa51b47d75e2f5bc762a718587470950cf195cb4
Reviewed-on: https://chromium-review.googlesource.com/329999
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
For the case of drawing with un-normalized integer vertex attributes,
we need to do some dynamic conversion in the VS. However, each
attribute can either be signed or unsigned, and our shader signature
code would treat both as a match, giving rise to a warning in the
D3D11 Debug runtime. It's unclear if this would give incorrect
results, but it certainly should not produce a warning.
BUG=angleproject:1329
Change-Id: I302d11b44e8a0ef981e89c181aefac5451a899b7
Reviewed-on: https://chromium-review.googlesource.com/329998
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
By making this a virtual call to BufferFactoryD3D (aka RendererD3D),
we can also stop having side-effects in the BufferD3D class of
creating a static buffer storage when we only want to know the space
required for some vertex elements.
This refactoring will aid implementation of VertexArray11 dirty bits.
BUG=angleproject:1327
Change-Id: I0e34c6e9f5da35edebc179d578ad9392dc0166db
Reviewed-on: https://chromium-review.googlesource.com/329741
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
reinterpret_cast should not be used to cast nullptr_t. This should fix
clang and also stops IntelliSense from complaining.
TEST=build on Windows
Change-Id: I4ba342172e36941f6a234fa4ed1369010527a790
Reviewed-on: https://chromium-review.googlesource.com/329901
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
This method doesn't need to call through to the VertexBuffer class,
since in only really depends on vertex format caps. This makes the
code local to the VertexDataManager, the only place it is used.
Refactoring patch only, for VertexArray11 dirty bits.
BUG=angleproject:1327
Change-Id: I315313a72a00186930d7f9b1091ccb91f37f9f96
Reviewed-on: https://chromium-review.googlesource.com/329740
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
This test was releasing a resource created with a queried device
after it released the D3D11 device. It is problematic because the
error was not caught by the swarming tests on the trybots, but did
show up on the Intel bot because it was not a swarming test.
BUG=589851
BUG=angleproject:1219
Change-Id: I7383640df9794aaf0e32e0a7c276ae3b22232050
Reviewed-on: https://chromium-review.googlesource.com/330001
Reviewed-by: Jamie Madill <jmadill@chromium.org>
This reverts commit 7208f6994c.
Still some failures on Intel, requires a slightly different solution.
BUG=589851
Change-Id: I6ac6599249e9e0f6319c917e04734cd48ca9274d
Reviewed-on: https://chromium-review.googlesource.com/329734
Reviewed-by: Jamie Madill <jmadill@chromium.org>
This is needed to enable removing GetDXGIFormatInfo calls, which are
difficult to use correctly due to a texture format being associated
with multiple DXGI formats. This is done in preparation of changing
some of the DXGI formats associated with integer textures.
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.fbo.* (no regressions)
Change-Id: I992c4c06189887c1b9de02f9b63dd9a474fcffab
Reviewed-on: https://chromium-review.googlesource.com/329094
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
With ESSL 3.00, names of built-in functions cannot be redeclared as
functions, and therefore an error needs to be generated if a built-in
function is overloaded.
This is fixed by inserting unmangled built-ins into a special set in
the symbol table and checking if function declarations match any of
the built-ins in the set.
The regular symbol table structures can't be used for storing the
unmangled names because that interferes with name hashing in
OutputGLSL.
Credit goes to Arun Patole, apatole@nvidia.com for initially
investigating this issue and developing the first version of the
patch.
BUG=angleproject:1066
TEST=angle_unittests,
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function*
(2 tests started passing with this change)
Change-Id: I28c8325f5a3a8f4a97226b0dfdbb9762724fa609
Reviewed-on: https://chromium-review.googlesource.com/328994
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
In the CopyNativeVertexData template function, in the else clause
use memcpy/memset rather than for loops. This is a performance
improvment for floating point versions of CopyNativeVertexData,
particularly on 32-bit Firefox, where the -arch:IA32 compiler
option used cause the compiler to generate fld/fstp operations
inside the for loops.
Update AUTHORS & CONTRIBUTORS to include AMD.
BUG=angleproject:1317
Change-Id: I7133fc476028284f56783f4e2f9e2395f6227514
Reviewed-on: https://chromium-review.googlesource.com/327590
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shannon Woods <shannonwoods@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
The destructor did not release D3D objects that could be in the
mPendingQueries list when the destructor is called. This fix now iterates
through the list and releases them.
BUG=angleproject:1325
Change-Id: Ia3bd2a8a611f8dbf85051ab5bfea18ab72038af5
Reviewed-on: https://chromium-review.googlesource.com/329426
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Ian Ewell <ewell@google.com>
It's needlessly complex to query texture info when determining whether
a format is a depth/stencil format. It can be tested simply by
checking if the dsvFormat field of the format set is set.
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.texture.specification.*depth* (no regressions)
Change-Id: I76d008462564657328dae35d664be5f5e22238fa
Reviewed-on: https://chromium-review.googlesource.com/329104
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
This is needed to enable removing GetDXGIFormatInfo calls, which are
difficult to use correctly due to a texture format being associated
with multiple DXGI formats. This is done in preparation of changing
some of the DXGI formats associated with integer textures.
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.fbo.* (no regressions)
Change-Id: I820b8331e6f9aacfe9979b13118371687c5fca51
Reviewed-on: https://chromium-review.googlesource.com/329075
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Making swizzle format data come from the ANGLE format table will make
it easier to make changes that affect both swizzle formats and regular
texture formats. Swizzle format is now specified manually for some
tricky formats, but for most it can be determined automatically from
the ANGLE texture format info.
The ANGLE texture format info in texture_format_table.json is changed
to facilitate this. The componentType field now captures only whether
the data is normalized, int or float and its signedness, but not the
width of the data type. Bit widths of the individual channels are
recorded in a separate "bits" object for each ANGLE format entry.
Also, a new 16-bit RGBA UNORM ANGLE format is added to support
swizzling 16-bit normalized depth formats.
This change is mostly just refactoring, but it fixes swizzling for
formats which have less bits for alpha than other channels:
- RGB10_A2
- RGB10_A2UI
- RGB5_A1
BUG=angleproject:1322
BUG=angleproject:1244
TEST=angle_end2end_tests,
dEQP-GLES3.functional.texture.swizzle.* (all pass)
Change-Id: I87d8a9cc0b6569191f50c41754d77b20ca6afef9
Reviewed-on: https://chromium-review.googlesource.com/329074
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
These tests seem to be flaky, and now they are showing up in
a bunch of CLs as failures.
BUG=angleproject:1324
Change-Id: I47c0e0895f8d87fba52084cf571fb453e5d996e0
Reviewed-on: https://chromium-review.googlesource.com/329279
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
These tests seem to be flaky, and now they are showing up in
a bunch of CLs as failures.
BUG=angleproject:1324
Change-Id: Ie7dd70bde1490c8623910c6d319128ca1225990a
Reviewed-on: https://chromium-review.googlesource.com/329156
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill
Frank Henigman
Olli Etuaho
Corentin Wallez
Ian Ewell
stal
Russ Lind