|
c4533eae
|
2018-09-19T15:23:29
|
|
Enable ANGLE_texture_multisample in glsl in es 3.0
Enable gsampler2dMS, texelFetch, textureSize in glslang in
es 3.0 if ANGLE_texture_multisample is supported.
Bug: angleproject:2275
TEST=SamplerMultisampleEXTTest.TextureMultisampleEXTEnabled
Change-Id: Ibfa367970db3ae790f3822e57eb50090843dc6db
Reviewed-on: https://chromium-review.googlesource.com/c/867521
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Yizhou Jiang <yizhou.jiang@intel.com>
|
|
f0d0408a
|
2018-08-28T16:02:13
|
|
Use OES_texture_storage_multisample_2d_array
There's an OES extension for multisample texture arrays,
OES_texture_storage_multisample_2d_array. Change references from
ANGLE_texture_multisample_array to the native extension in the shader
compiler.
ANGLE still needs to have robust behavior for out-of-range texel
fetches that's not found in the original extension, but this does not
need to be spelled out in the extension spec.
BUG=angleproject:2775
TEST=angle_unittests
Change-Id: Ie80ae767cc92ccaf7389af28789f45547f86978f
Reviewed-on: https://chromium-review.googlesource.com/1193266
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
8ca60805
|
2018-08-23T14:10:02
|
|
Add 2D MS array sampler support to compiler
This also places textureSize(gsampler2DMS) correctly in the ESSL 3.10
builtins instead of ESSL 3.00 builtins.
BUG=angleproject:2775
TEST=angle_unittests
Change-Id: Ieb0f7a7424a5558a5569af6d4fcbcc9b12ec9840
Reviewed-on: https://chromium-review.googlesource.com/1186466
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
a6a7842f
|
2018-06-28T08:32:54
|
|
ES31: Support atomic functions on D3D11 - Part I
This patch is the first one of the implementation of atomic
functions in D3D11.
There are mainly two differences in the usage of GLSL and HLSL
atomic functions:
1. All GLSL atomic functions have return values, which all
represent the original value of the shared or ssbo variable;
while all HLSL atomic functions don't, and the original value
can be stored in the last parameter of the function call.
2. For HLSL atomic functions, the last parameter that stores the
original value is optional except for InterlockedExchange and
InterlockedCompareExchange. Missing original_value in the call
of InterlockedExchange and InterlockedCompareExchange results
in a compile error from HLSL compiler.
To handle these differences, we plan to implement the translation
in two steps:
1. Support direct translations from GLSL atomic functions to HLSL
ones.
Direct translation can only handle the following two situations:
(1) The sentence is a GLSL atomic function call without requesting
a return value and it is not atomicExchange or atomicCompSwap:
e.g.
GLSL: atomicAdd(mem, value);
-> HLSL: InterlockedAdd(mem, value);
(2) The sentence is a simple assignment expression: its right is
a GLSL atomic function call and its left is a declared variable.
e.g.
GLSL: oldValue = atomicAdd(mem, value);
-> HLSL: InterlockedAdd(mem, value, oldValue);
2. Support atomic functions in the situations that don't support
direct translations.
We will modify the intermediate tree to make direct translation work
on all these situations.
e.g.
atomicExchange(mem, value);
-> int oldValue;
oldValue = atomicExchange(mem, value);
int oldValue = atomicAdd(mem, value);
-> int oldValue;
oldValue = atomicAdd(mem, value);
return atomicAdd(mem, value);
-> int temp;
temp = atomicAdd(mem, value);
return temp;
for (i = 0; i < atomicAdd(mem, value); ++i)
-> int temp;
temp = atomicAdd(mem, value);
for (i = 0; i < temp; ++i)
{
...
temp = atomicAdd(mem, value);
}
int result = isTrue ? atomicAdd(mem, value) : 0;
-> int result;
if (isTrue)
{
result = atomicAdd(mem, value);
}
else
{
result = 0;
}
This patch completes Step 1 which mainly focus on the translation
from GLSL atomic functions to HLSL ones.
BUG=angleproject:2682
TEST=angle_end2end_tests
Change-Id: I3b655b6e286dad4fd97f255f7fe87521c94db30c
Reviewed-on: https://chromium-review.googlesource.com/1121835
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
2bfe9f6b
|
2018-03-02T16:53:29
|
|
Use function id to group functions in ParseContext
This way we can do numeric comparisons instead of string comparisons.
The effect on compiler perf test scores is fairly marginal, but
this reduces binary size by a few kilobytes, and there may be a larger
effect on shaders calling a lot of texture functions.
BUG=angleproject:2267
TEST=angle_unittests
Change-Id: I077db97b16b16b70b7e18ee037e06d7450d08dc9
Reviewed-on: https://chromium-review.googlesource.com/947952
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
24180607
|
2018-03-02T14:12:13
|
|
Allow rectangle textures to be sample with texture() in ESSL3
This makes them consistent with the other texture types. Also adds a
test for using texture(sampler2DRect, ...).
BUG=chromium:757974
BUG=angleproject:1650
Change-Id: Ie966da928ae0c83850da1e530e72c0d501909394
Reviewed-on: https://chromium-review.googlesource.com/946675
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
140152e7
|
2018-02-08T14:46:44
|
|
Statically allocate built-in function symbols
A script gen_builtin_symbols.py now generates code for initializing
built-in function symbols. The TFunction objects are initialized at
C++ compile time.
The source file used for the functions is in a format that's similar
to how functions are given out in the GLSL spec, so it is easy to
maintain.
The function symbols are still inserted to the symbol table levels
same as before. Getting rid of inserting the symbols at runtime is
intended to be done as follow-up.
This speeds up angle_unittests on Linux in release mode by a bit less
than half, and in debug mode by more than half.
BUG=angleproject:2267
TEST=angle_unittests
Change-Id: I11c9de98c74d28e7e8cdf024516e2f6ee30ca33e
Reviewed-on: https://chromium-review.googlesource.com/924155
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|