Bug: b/146579770
Tests: dEQP-VK.*
Change-Id: Ibd383e01c9fce41faf3c26deb4aefa6bc056cfdb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46068
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Fixes out-of-bounds reads/writes and also avoids unaligned accesses.

This is a generic reference implementation. Future optimizations could
use unaligned 4-byte accesses if they're known to be safe (e.g. due to
padding) and efficient. We can also eliminate if we know we're in a
basic block post-dominated by the entry block and the number of
active invocations is a multiple of the SIMD width.

Bug: b/160531165
Change-Id: I892cfd3c7da8d8891cabe80695e5f35c57da73b4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46168
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

The Reactor code in floatToHalfBits() did not match the reference
implementation of the sw::half type, leading to failures in dEQP tests
which are enabled by the shaderStorageImageExtendedFormats feature.

The previous code was based on https://gist.github.com/rygorous/2156668.
It doesn't round to nearest even in case of a tie, but that's not
demanded by Vulkan. It merits a closer look to see whether there was a
bug, or whether dEQP-VK is too strict. Dawn also found the previous
implementation to not handle infinity correctly, so a bug seems likely.

In any case, it's good to use a reference implementation for now, and
look for optimization opportunities later.

Bug: b/147900455
Bug: swiftshader:147
Tests: dEQP-VK.image.format_reinterpret.buffer.*_b10g11r11_ufloat_pack32
Change-Id: Id817a012ff38af814907c2de2914ec24565622f3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46148
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Images with dimensions of 65536 texels or more exceed the 16-bit logic
used by our 'low' precision sampler code. Thus we were treating them
differently and forced them to use our 32-bit code path. However,
ordinary images can't have such large dimensions. Only texel buffers
must support 65536 or more texels.

Those can only be accessed by OpImageFetch, OpImageRead, and
OpImageWrite instructions, and the latter two already use custom 32-bit
addressing logic. Thus we can simply specify all Fetch operations to
use the 32-bit sampler code path instead of differentiating based on
resource dimensions.

This fixes dEQP robustness tests which are enabled by the
shaderStorageImageExtendedFormats feature, because the 16-bit code path
does not bounds check fetch coordinates correctly.

Note that fetch does not perform filtering, and thus there is no excess
from using 32-bit filtering code.

Bug: b/152224843
Tests: dEQP-VK.robustness.buffer_access.*.texel_copy.a2b10g10r10_unorm_pack32.oob_uniform_read.*
Change-Id: Ie658e0fc9da05cad8efec58bac3238fb498ff10b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46131
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

- Removed unnecessary Min() for R8G8B8A8_SNORM
  (see https://www.khronos.org/registry/vulkan/specs/1.1/html/vkspec.html#fundamentals-fixedfpconv)​
- Removed redundant parenthesis.
- Used hexadecimals for the normalization factor (to match mask).
- Used uppercase for hexadecimals.
- Used decimal point for floating-point constants.

Bug: b/159561781
Change-Id: I4eed4be3ec9b58bb43652de396bd3a34813eb283
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46010
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

VK_FORMAT_R8_SNORM, R8G8_SNORM, and A8B8G8R8_SNORM_PACK32 are mandatory
uniform texel buffer formats, which we claimed support for, but their
implementation was missing.

Bug: b/159561781
Change-Id: Ia66d14cd8189a664bf41af7d918260d2524aa63a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46009
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

VK_FORMAT_B10G11R11_UFLOAT_PACK32 is a mandatory uniform texel buffer
format, which we claimed support for, but the implementation was
missing.

Bug: b/159561781
Change-Id: I47a1aa3d4f371603e4d97e85526e10677753b9ca
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46008
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

A few struct members were only ever written to and never read, which
means these were encoder only struct members. Since we only need the
ASTC decoder, these encoder only struct members were removed.

The gains in memory allocation sizes are substantial:

block_size_descriptor
Initial size: 3469056 B (~3.3 MB)
After this cl: 693168 B (~677 kB)

decimation_table
Initial size: 364896 B (~356 kB)
After this cl: 1948 B (~1.9 kB)

Change-Id: Id86c993331d2602a1106f6aaa729d1047e2ebc27
Tests: dEQP-VK.*astc*
Bug: b/150130101
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46128
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

It was being set as a C++ compile flag, while it's an MSVC linker flag.
The /D was interpreted as a macro definition, which caused an
IntelliSense error.

Also fix the set_linker_flag CMake macro to correctly append the build
configuration.

Bug: b/147735529
Change-Id: I0e4473a07c224b64ad0aeb54390bced087eea3d8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46088Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

This is a cherry pick of upstream LLVM r340889.

Bug: b/74603866
Change-Id: I9d0fd16d20d690b5c930e0a915dad8247890fc38
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46048Tested-by: Peter Collingbourne <pcc@google.com>
Presubmit-Ready: Peter Collingbourne <pcc@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

The original fix for b/139528538 didn't differentiate between release
and debug builds properly. It just just checked to see if a debugger was
attached.

Now the assert will only happen when a debugger is attached and in a
debug build.

Bug: b/159733084
Change-Id: I9a6407685225c662aeb378be3296b8e4640b279d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46028
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Extend Blitter::fastClear(), which is based on memset() instead of using
Reactor routines, to also handle D32_SFLOAT and S8_UINT formats.

Benchmark results:

Run on (48 X 2594 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x24)
  L1 Instruction 32 KiB (x24)
  L2 Unified 256 KiB (x24)
  L3 Unified 30720 KiB (x2)
--------------------------------------------------------------------------
Benchmark                                Time             CPU   Iterations
--------------------------------------------------------------------------
(LLVM, before)
ClearImage/VK_FORMAT_D32_SFLOAT       3.74 ms        0.016 ms         1000

(LLVM, after)
ClearImage/VK_FORMAT_D32_SFLOAT       1.08 ms        0.044 ms        10000

(Subzero, before)
ClearImage/VK_FORMAT_D32_SFLOAT       4.51 ms        0.063 ms         1000

(Subzero, after)
ClearImage/VK_FORMAT_D32_SFLOAT      0.963 ms        0.040 ms         7467

This change re-implements https://swiftshader-review.googlesource.com/c/SwiftShader/+/45888
which was reading 'clearValue' out of bounds when accessing color[1]
when it's only a single depth or stencil value.

Bug: b/159455503
Bug: chromium:1097740
Change-Id: Id3e74b4fa28ee0422540a8480814f8c9988f402a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45949
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Bug: chromium:1098899
Change-Id: Iad5cd599e7e90f29249d0e4129ca1fe4a10d77c6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46029
Presubmit-Ready: Nico Weber <thakis@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nico Weber <thakis@google.com>

This will help ensure we don't break these configs.

Bug: b/159633249
Change-Id: Ida7074a649c10a1a5b35ce82b4f8438b65bdb3eb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45970
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

Also simplify code so that emitPrintLocation is called, but does nothing
if ENABLE_RR_EMIT_PRINT_LOCATION isn't defined.

Bug: b/159633249
Change-Id: I0e207baf6a0e2eb144e026904357664e1277ebf1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45969
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

This is as close as we'll get to "set -e" from bash. Makes the script
less verbose, and closer to the Linux and MacOS ones.

Bug: b/159633249
Change-Id: Ied7cdb5ab11b737fb21379be912393bbd838a40a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45968
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

This reverts commit af1f2159.

Reason for revert: Fails tests with ASAN crbug.com/1097740

Bug: chromium:1097740
Change-Id: I48d3d1129ad3ea314df29d1f40b595ad6fa169ce
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45928Reviewed-by: Corentin Wallez <cwallez@google.com>
Tested-by: Corentin Wallez <cwallez@google.com>

The Vulkan spec states that "blendEnable [...] must be VK_FALSE if the
attached image’s format features does not contain
VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT"

Previously we would silently ignore blending of integer formats. It was
determined to be undefined behavior in https://gitlab.khronos.org/vulkan/vulkan/issues/2098

Bug: b/155147929
Change-Id: I01500d8c39d7f2c9a484944b4a93c6004e938c05
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45708
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

A highly generic Blitter::blitToBuffer() method was used for copying
pixels without requiring any format conversion or scaling.

This change removes Blitter::blitToBuffer() and the unused
blitFromBuffer() methods and implements a copyTo() method which does
straightforward memcpy() of the data.

Also consistently add 'To' and 'From' to the Image class's copy, blit,
and resolve methods to avoid any confusion about which direction the
transfer happens.

Benchmark results:

Run on (48 X 2594 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x24)
  L1 Instruction 32 KiB (x24)
  L2 Unified 256 KiB (x24)
  L3 Unified 30720 KiB (x2)
---------------------------------------------------------
Benchmark               Time             CPU   Iterations
---------------------------------------------------------
(LLVM, before)
Triangle/Hello       8.69 ms         7.39 ms          112

(LLVM, after)
Triangle/Hello      0.878 ms        0.454 ms         2133

(Subzero, before)
Triangle/Hello       26.2 ms         24.8 ms           41

(Subzero, after)
Triangle/Hello       1.11 ms        0.432 ms         1339

Bug: b/147967959
Change-Id: I76a103bbb6e582f987ef1c3cc39d17779ae4ac99
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45650
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

Extend Blitter::fastClear(), which is based on memset() instead of using
Reactor routines, to also handle D32_SFLOAT and S8_UINT formats.

Benchmark results:

Run on (48 X 2594 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x24)
  L1 Instruction 32 KiB (x24)
  L2 Unified 256 KiB (x24)
  L3 Unified 30720 KiB (x2)
--------------------------------------------------------------------------
Benchmark                                Time             CPU   Iterations
--------------------------------------------------------------------------
(LLVM, before)
ClearImage/VK_FORMAT_D32_SFLOAT       3.74 ms        0.016 ms         1000

(LLVM, after)
ClearImage/VK_FORMAT_D32_SFLOAT       1.08 ms        0.044 ms        10000

(Subzero, before)
ClearImage/VK_FORMAT_D32_SFLOAT       4.51 ms        0.063 ms         1000

(Subzero, after)
ClearImage/VK_FORMAT_D32_SFLOAT      0.963 ms        0.040 ms         7467

Bug: b/159455503
Change-Id: Ib1b0ad38417c516267d6addd835076a933e22dba
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45888
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

The spec for VkDescriptorSetLayoutBinding states that
"If descriptorCount is zero this binding entry is reserved and the
resource must not be accessed from any stage via this binding within any
pipeline using the set layout."

This restores the debug validation that existed at https://swiftshader-review.googlesource.com/c/SwiftShader/+/44308/4/src/Pipeline/SpirvShaderMemory.cpp#b405

Bug: b/157915024
Change-Id: I5e6798b0cc87f564a3c6f13963995822660b5111
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45468Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Also separate the out-of-bounds handling from the offset calculations.

Bug: b/155862459
Change-Id: Ib6c5ea029d16fc411d792e6c129b37386d48fc1d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45092Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Adding large values can overflow the already out-of-bounds offsets to
become negative. Negative offsets are not detected as out-of-bounds, so
it would result in an out-of-bounds access. This can also happen when
they were already large negative values and remain negative after
the addition. Or, when they're small negative values, they can become
in bounds and thus not trigger the desired out-of-bounds behavior.

Just replace the offsets with the out-of-bounds values.

Bug: b/155862459
Change-Id: I38a45832bfea3a13a66f133ee7c2162855f02c61
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45091
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

This refactors the benchmarks to use static functions which support
passing arbitrary arguments, instead of fixtures:
https://github.com/google/benchmark#passing-arbitrary-arguments-to-a-benchmark

This makes it easier to have a variant with and without multisampling,
and avoids using state.counters[] as a hack to display clear formats.

Bug: b/158231104
Change-Id: Icf0eed254dc942af8f2bcfc975a1e5e581b6e786
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45790
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Adds a Framebuffer class to encapsulate and abstract framebuffer
creation with or without multisampling.

Bug: b/158231104
Change-Id: I4198f53f872aae76955ba13f1f2372067b91a07c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45789
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

For now, this has to be enabled manually using
TriangleBenchmark::multisample

Bug: b/158231104
Change-Id: I929da4bf72e6f354aeb089e19fdd6a749f839d3f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45689
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Initialization of thread_local variables in shared libraries might be
implementation dependent.

Just keep the assert for Win32.
https://docs.microsoft.com/en-us/cpp/cpp/thread?view=vs-2019 states that
"Thread-local variables that are initialized statically with constant
values are generally initialized properly on all threads."

Bug: b/157525646
Change-Id: Ifb6a77e085c0f21f13af58c89050868992928300
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45809
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

The Vulkan specification for VkGraphicsPipelineCreateInfo states:
 * pViewportState is a pointer to a VkPipelineViewportStateCreateInfo structure, and is ignored if the pipeline has rasterization disabled.
 * pMultisampleState is a pointer to a VkPipelineMultisampleStateCreateInfo structure, and is ignored if the pipeline has rasterization disabled.
 * pDepthStencilState is a pointer to a VkPipelineDepthStencilStateCreateInfo structure, and is ignored if the pipeline has rasterization disabled or if the subpass of the render pass the pipeline is created against does not use a depth/stencil attachment.
 * pColorBlendState is a pointer to a VkPipelineColorBlendStateCreateInfo structure, and is ignored if the pipeline has rasterization disabled or if the subpass of the render pass the pipeline is created against does not use any color attachments.

Also remove the UNSUPPORTED() for pTessellationState since it is valid
for the application to provide a non-null pointer even though
tessellation is not supported.

Bug: b/155359026
Change-Id: Ic1cd9224b159cca66f0dbf1b1a563efc56386866
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45728
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Using an initialization method or in-class initialization of each member
is bug-prone. Zero-initialization performed by the default constructor
guarantees repeatability.

Also don't skip drawing when the multisample mask is zero. Pipeline
stages prior to fragment processing may have side-effects.

Bug: b/155359026
Change-Id: Ibab131a41282fbdc4f5f84208776725eb3c786bd
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45748
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

VkImage use different structures to represent subregions:
- VkImageSubresource (Single mip level, single layer)
- VkImageSubresourceLayers (Single mip level, multiple layers)
- VkImageSubresourceRange (Multiple mip levels, multiple layers)

This cl changes the subregion structure used in vk::Image and in the
Blitter so that it contains the information required for the current
task and no more than that.

Bug: b/159045555
Change-Id: I186a90ff321318319c01a0718a95bbae2d2eb26a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45788
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Changes:
    d29553a3730 Add missing <vector> include

Commands:
    ./third_party/update-marl.sh --squash

Bug: b/140546382
Change-Id: Ibb19c64cd2cbbd4b71ddd8270d1b3541a123cbca

d29553a3730 Add missing <vector> include

git-subtree-dir: third_party/marl
git-subtree-split: d29553a3730f2bbe7ab4afd37e926e787faae4a0

Changes:
    5c6c1532220 Fix Android build

Commands:
    ./third_party/update-marl.sh --squash

Bug: b/140546382
Change-Id: Ibb733d85c64a183f4fbe1a803d3d569a37e858a1

5c6c1532220 Fix Android build

git-subtree-dir: third_party/marl
git-subtree-split: 5c6c1532220096dd470549312053a445d7d95a2c

* changes:
  Update Marl to c51271125
  Squashed 'third_party/marl/' changes from 38c0c7a0f..c51271125
  Repoint marl branch from master to main
  SubzeroReactor: Use new marl::Scheduler::Config API.

In-memory data visualizations of vector types were using indices
for displaying vector elements. For non-memory data, we use
.x .y .z .w for vectors <= 4 elements.

Mirror this for in-memory data.

Bug: b/148401179
Change-Id: Ib2e8e2019ab274dfae2d6e18978f41c721c800a1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45609
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

to debug::Object. This used to be unnecessary as the debug objects used
to contain POD, but we now also have std::string and std::vector fields
in these objects, and we need them to destruct.

Bug: b/148401179
Change-Id: I28637f645a96e3e895e7ae5f3028eb7872c92dd3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45608
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Changes:
    c51271125 README.md: Repoint link from `master` to `main`
    da0a9c610 Add basic CMake rules for versioning marl
    0e639c3c7 Benchmarks: Simplify tests further.
    32af8bb50 Kokoro: Enable debug checks
    8cf8dc033 Wrap all stl containers with a marl::StlAllocator
    325b072b9 Support specifying worker thread affinities
    49fe9a17f marl::containers: Add const methods
    11f31bfbe Benchmarks: Warn if benchmarking with sanitizers
    bfdf613e7 Benchmarks: Add MARL_FULL_BENCHMARK flag
    5e2383370 Benchmarks: Allow running with custom Config
    c277c61b0 marl::containers::vector fixes
    fcbe1f279 Add issue number to MARL_DEPRECATED()
    1f010cad7 Warn about use of deprecated APIs
    d2e553bff Don't use deprecated scheduler methods

Commands:
    ./third_party/update-marl.sh --squash

Bug: b/140546382
Change-Id: I3e59c425cbdc868e5de44a00a5523392044a3352

c51271125 README.md: Repoint link from `master` to `main`
da0a9c610 Add basic CMake rules for versioning marl
0e639c3c7 Benchmarks: Simplify tests further.
32af8bb50 Kokoro: Enable debug checks
8cf8dc033 Wrap all stl containers with a marl::StlAllocator
325b072b9 Support specifying worker thread affinities
49fe9a17f marl::containers: Add const methods
11f31bfbe Benchmarks: Warn if benchmarking with sanitizers
bfdf613e7 Benchmarks: Add MARL_FULL_BENCHMARK flag
5e2383370 Benchmarks: Allow running with custom Config
c277c61b0 marl::containers::vector fixes
fcbe1f279 Add issue number to MARL_DEPRECATED()
1f010cad7 Warn about use of deprecated APIs
d2e553bff Don't use deprecated scheduler methods

git-subtree-dir: third_party/marl
git-subtree-split: c51271125451c599efb9ec58b355a4c434296a8f

See https://github.com/google/marl/issues/153 for more details

Bug: b/140546382
Change-Id: I73cd3e575b781890e82eda94285e8a585bd879d5