|
71e6afb1
|
2020-01-14T14:12:31
|
|
Vulkan: Set set/binding in SPIR-V
This change introduces a SPIR-V transformer that modifies shader
interface variable decorations directly in SPIR-V instead of
manipulating the input GLSL. Currently, descriptor set and binding
indices are set by the transformer.
The shader translator outputs arbitrary set and binding indices. Once
compiled by glslang, the SPIR-V transformer modifies these decorations.
The ultimate goal is to be able to modify the SPIR-V again when program
pipeline objects decide a different set/binding is necessary.
Bug: angleproject:3394
Change-Id: If358265a72bf1fe9f5676562b39a632cb2e05dc4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2001477
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
86d9c93a
|
2019-12-16T16:07:04
|
|
Use TSpan for TType's array sizes
Until C++20, std::vector doesn't have a constexpr constructor, which
means TType cannot use a `TVector` for `mArraySizes` if an arrayed type
needs to be created constexpr. This is needed for the upcoming
textureGatherOffsets implementation.
A new TSpan class is introduced, based on std::span (from C++20) that
holds the pointer/size allocated from a TVector without owning it.
Since TVector's allocation are made from a pool, the allocated memory
will live beyond the vector's destruction. `TType::mArraySizes` is
changed to this type.
This change will allow a new constexpr constructor to be added to TType
that takes a TSpan as array directly, a value which is constexpr
initialized from a static array (instead of TVector).
Bug: angleproject:3569
Change-Id: I78793b0f4c64519e0ebe30cf6e0de995ba70035d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1968260
Reviewed-by: Jiajia Qin <jiajia.qin@intel.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
472c74c6
|
2019-08-19T16:32:13
|
|
Translator: Allow tree validation in children of TCompiler
This is to be able to perform validation inside TranslatorVulkan, even
if it's through ASSERTs.
Additionally, every transformation is changed such that they do their
validation themselves. TIntermTraverser::updateTree() performs the
validation, which indirectly validates many of three tree
transformations. Some of the more ancient transformations that don't
use this function directly call TCompiler::validateAST.
Bug: angleproject:2733
Change-Id: Ie4af029d34e053c5ad1dc8c2c2568eecd625d344
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1761149
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
7e48c9eb
|
2019-08-06T17:17:19
|
|
Add explicit integer casts
WebKit uses the -Wshorten-64-to-32 flag which warns on these cases.
Bug: 3439
Change-Id: I8c1de60da0f173ca2036e2120e79b857f5f2775f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1740866
Commit-Queue: James Darpinian <jdarpinian@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
c9ba782a
|
2019-08-05T16:14:22
|
|
Vulkan: Support atomic counter array of arrays
Previously, it was assumed that a function argument is either AC or
AC[i], and it was converted to AC or AC+i respectively. The code is
changed to support any number of dimensions and subscripts, using
array size information from AC's type. If AC is an array of array
(atomic_uint AC[N][M][R]), the following index calculations are done.
AC -> AC.arrayIndex
AC[i] -> AC.arrayIndex + i*M*R
AC[i][j] -> AC.arrayIndex + i*M*R + j*R
AC[i][j][k] -> AC.arrayIndex + i*M*R + j*R + k
A test is added to exercise these various forms of indexing:
AtomicCounterBufferTest31.AtomicCounterArrayOfArray
Bug: angleproject:3566
Change-Id: I1e181a7363463d1d0ee4916f35006ed7c58e0f7c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1739488
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
0296e169
|
2019-08-02T14:38:45
|
|
Vulkan: Refactor atomic counter retype code
A generic "retyper" class is extracted out of the atomic counter retype
code to be used with coverting samplerCube to sampler2DArray for seamful
cubemap sampling emulation.
Bug: angleproject:3732
Change-Id: I8b5f835125b9513afcfe7baeea48afaf1299a027
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1733807
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
44e690ca
|
2019-07-22T16:42:55
|
|
Vulkan: Support unaligned atomic counter buffer binding
GLES doesn't require any implementation-specified alignment requirement
for atomic counter buffers. They are emulated with Vulkan storage
buffers, which do have restrictions.
The storage buffers are bound at aligned offsets, and the remaining
offsets are passed to the shader as uniform values. This means that the
driver uniforms are now also bound to the compute pipeline.
Bug: angleproject:3566
Change-Id: I1a3429438f76d95e33cb5c6ef2c9370a10d900d6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1713095
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
c13ca2af
|
2019-07-17T15:46:29
|
|
Vulkan: Allow more than one atomic counter buffer binding
dEQP assumes there are more than one atomic counter buffers available.
This is technically not a requirement by the standard, but nevertheless
could be what applications expect as well.
This change adds support for multiple atomic counter buffer bindings.
This is done by declaring an array of storage buffers for the atomic
counter buffers (instead of declaring only one) and passing the
(binding, offset) pair around to functions instead of just the offset.
The atomic counter is found by indexing `binding` into the storage
buffer array first before indexing `offset` into its `uint[]`.
ProgramVk's default uniform collection is also fixed not to include
atomic counter uniforms.
A remaining issue is that atomic counter buffer offsets don't have
alignment requirements in GLES, but Vulkan does for storage buffers.
Similar to emulated transform feedback buffer offsets, these should be
sent to the shader through uniform values. This will be done in a
follow up change.
Bug: angleproject:3566
Change-Id: I5600225c24c38f1a8ecf5c64388073055733197d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1707931
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
b82d8633
|
2019-07-15T11:23:08
|
|
Vulkan: Atomic counter buffer support
Vulkan doesn't treat atomic counters especially, and they are emulated
with atomic access to storage buffers.
A single atomic counter buffer binding per pipeline is supported. All
the atomic counters identify an offset within this buffer. The shader
is modified to include a storage buffer definition with
`uint counters[];` as the only field.
A compiler pass replaces atomic counter definitions with variables that
hold the corresponding offset parameter, as well as changing atomic_uint
types to just uint (as the offset). Where an atomic counter variable is
used, it is replaced with the offset variable (plus the array index, if
array). At the same time, built-in `atomicCounter*` functions are
replaced with a corresponding `atomic*` function and
`memoryBarrierAtomicCounter` is replaced with `memoryBarrierBuffer`.
Bug: angleproject:3566
Change-Id: Iefb3d47de6a5cb3072bfa0cb94a46ac6a886d369
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1704635
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|