|
bda75597
|
2016-04-18T17:25:54
|
|
Finish NV12 support via streams.
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>
|
|
9670b03e
|
2016-04-29T09:47:47
|
|
Revert "Finish NV12 support via streams."
Broke Windows Clang compilation, see https://build.chromium.org/p/chromium.gpu.fyi/builders/GPU%20Win%20Clang%20Builder%20%28dbg%29/builds/3583/steps/compile/logs/stdio and search for TextureStorage11.h
This reverts commit 9b8b359fa3615be7c7492239a48f61103b2e4fcc.
Change-Id: I6e54305eba02b40927a35577594df39e951adb32
Reviewed-on: https://chromium-review.googlesource.com/341430
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
|
|
9b8b359f
|
2016-04-18T17:25:54
|
|
Finish NV12 support via streams.
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>
|
|
5858f7e3
|
2016-04-08T13:08:46
|
|
Re-land "Refactor texture function handling in OutputHLSL"
This change is pure refactoring, it does not introduce any functional
changes.
Separate texture function output into a helper class and further into
different helper functions to make the code more maintainable.
Some of the logic is simplified slightly by eliminating duplicate
cases and limiting the scope of variables where possible, but care
has been taken to preserve the exact same functionality as before.
Re-land with a fix to typo in include guard.
BUG=angleproject:1349
TEST=dEQP-GLES3.functional.shaders.texture_functions.* (no regression)
dEQP-GLES3.texture.* (no regression)
Change-Id: I57c1ec1950fa05bd16275ca578eb5ee99b34a5ae
Reviewed-on: https://chromium-review.googlesource.com/339180
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
c2ed9380
|
2016-04-15T13:29:25
|
|
Revert "Refactor texture function handling in OutputHLSL"
It triggered an include guard warning on Windows Clang
This reverts commit 6f6c5580553d1f3c584df692823c2f5640e23d88.
Change-Id: Ibd4f2851f311a494f16376d8eed38f3119594761
Reviewed-on: https://chromium-review.googlesource.com/338933
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
|
|
6f6c5580
|
2016-04-08T13:08:46
|
|
Refactor texture function handling in OutputHLSL
This change is pure refactoring, it does not introduce any functional
changes.
Separate texture function output into a helper class and further into
different helper functions to make the code more maintainable.
Some of the logic is simplified slightly by eliminating duplicate
cases and limiting the scope of variables where possible, but care
has been taken to preserve the exact same functionality as before.
BUG=angleproject:1349
TEST=dEQP-GLES3.functional.shaders.texture_functions.* (no regression)
dEQP-GLES3.texture.* (no regression)
Change-Id: I5d81b842d693c0055890d5724eae6c105e454cd8
Reviewed-on: https://chromium-review.googlesource.com/337931
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
|
|
9696316d
|
2016-03-21T11:54:33
|
|
Support ESSL structs containing samplers on D3D
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>
|
|
be59c2fb
|
2016-03-07T11:32:34
|
|
Fix ambiguous function call issues in HLSL output
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>
|
|
9b4e8626
|
2015-12-22T15:53:22
|
|
Redesign samplers in shaders on D3D11
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>
|
|
59f9a641
|
2015-08-06T20:38:26
|
|
Remove EOpInternalFunctionCall
It's cleaner to mark internal functions by using the TName class,
similarly to TIntermSymbol.
TEST=angle_unittests
BUG=angleproject:1116
Change-Id: I12a03a3dea42b3fc571fa25a1b11d0161f24de72
Reviewed-on: https://chromium-review.googlesource.com/291621
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
f5cfc8df
|
2015-08-06T16:36:39
|
|
Track whether a name is internal to ANGLE in a separate class
The AST contains identifiers in a few different places: besides symbols,
there are also function names, which show up in function signatures
and function calls. Any of these can be coming either from the original
shader or from inside ANGLE. A class that encapsulates a string and its
internalness will be useful for implementing a unified way of handling
all names in shader translation. Start implementing this by splitting
the functionality out of TSymbol.
TEST=angle_unittests
BUG=angleproject:1116
Change-Id: I0a1b5936dcccd0d5fc1c0c13c712102fbfff2a79
Reviewed-on: https://chromium-review.googlesource.com/291280
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
214c2d8e
|
2015-04-27T14:49:13
|
|
Separate invariance from qualifiers
ESSL3 makes it possible to combine invariant with several more different
qualifiers. To avoid combinatorial explosion of the qualifier enum, track
invariance with a separate boolean.
TEST=WebGL conformance tests, angle_unittests
BUG=angleproject:987
Change-Id: I0c6629e5ca2ded06db9ac9e5bab2fb6480299a5a
Reviewed-on: https://chromium-review.googlesource.com/267662
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
9b82084f
|
2015-02-12T10:40:10
|
|
Fix HLSL varying struct linking.
We would always expand a struct name to always include its symbol
ID. This fixes the workaround to only affect scoped structs.
We can leave global structs, which are by definition uniquely named,
without decorating them with a symbol ID.
This fixes several tests in dEQP's shader.linkage.varying.struct.
Re-land with GLSL translator bug fixed.
BUG=angle:910
Change-Id: I23a932bd1dadea5e9aafabde697e6a2af9a43f2b
Reviewed-on: https://chromium-review.googlesource.com/249134
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
b960cc4a
|
2015-02-12T15:33:20
|
|
Revert "Allow varying structs to match between stages."
This patch has a bug which breaks the GLSL to GLSL translator.
See broken GPU FYI bot builds on the Chromium waterfall:
http://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28NVIDIA%29/builds/13074
This reverts commit 489ffc4d69656c2dbfdbe07e3fa6e38baeb3e072.
Change-Id: I8241c6d658f4f31af91b89af1141d3d778ff7c70
Reviewed-on: https://chromium-review.googlesource.com/249131
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
489ffc4d
|
2015-02-11T16:33:07
|
|
Allow varying structs to match between stages.
We would always expand a struct name to always include its symbol
ID. This workaround fixed scoped structs with the same name. It
would also block any possiblity of linking the structs successfully.
Instead we can use the workaround only on inner-scoped structs, and
leave global structs, which are by definition uniquely named, as
they are.
This fixes several tests in dEQP's shader.linkage.varying.struct.
BUG=angle:910
Change-Id: I81b8dadc7ea493152aff0c44d607114eaaabb142
Reviewed-on: https://chromium-review.googlesource.com/247242
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
d5512cd4
|
2014-07-10T17:50:08
|
|
Collect shader outputs and interface block information.
This paves the way for returning ES3-specific info from the shader
translator with the new query methods.
BUG=angle:466
Change-Id: Ib13cdb604854cdf11e9dc00dd94f18eadc946561
Reviewed-on: https://chromium-review.googlesource.com/206770
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
|
|
8daaba15
|
2014-06-13T10:04:33
|
|
Split OutputHLSL structure code into new module.
Refactoring patch only.
BUG=angle:466
Change-Id: I2c57096e1e24574e7de3d35d608645fde3b0c681
Reviewed-on: https://chromium-review.googlesource.com/203730
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
|
|
033dae67
|
2014-06-18T12:56:28
|
|
Move OutputHLSL utility methods to other files.
OutputHLSL was become a large, unweildy file. Some were also useful
to other classes, even on the GL back-end, but were inacessible.
Refactoring patch only.
BUG=angle:466
Change-Id: Id216147122ca105c6ccdf0ba0c5f6c5038726965
Reviewed-on: https://chromium-review.googlesource.com/203459
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|