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

`marl::Scheduler::setWorkerThreadCount()` and `marl::Scheduler::setThreadInitializer()` have been deprecated.
`marl::Scheduler::Config` is the new API.

This got missed from 45493.

See https://github.com/google/marl/issues/139 for context.

Bug: b/140546382
Change-Id: Ic09c196b4c81f316cbf73de5395757108c16945c

This change now also makes it so that when rr::Print is enabled, it will
output to stdout and to the debugger, if available. For now, that means
it calls OutputDebugString on Windows. This is useful when it is
difficult to capture stdout (e.g. debugging Chrome).

Also, you can now modify Reactor.cpp and uncomment
`#define RR_PRINT_OUTPUT_TYPE_STUB` to stub out the function itself.
This is useful in combination with ENABLE_RR_EMIT_PRINT_LOCATION in that
debugging the code-gen assembly allows you to inspect the string
argument to rr::DebugPrintf and see exactly where you are in Reactor
code without paying the performance cost of actually printing.

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

The 37 failures in dEQP-VK.texture.explicit_lod.2d.* originated
from a dEQP test issue which is now fixed:
https://github.com/KhronosGroup/VK-GL-CTS/commit/ad89e118084d08fa1f14ad5801b996c62eb113cc

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

https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkShaderModuleCreateInfo.html
states that the "code must adhere to the validation rules described by
the Validation Rules within a Module section of the SPIR-V Environment
appendix"

This makes it the application's responsibility to only pass valid SPIR-V
code to vkCreateShaderModule. However, improperly validated code
may cause bugs which are hard to root cause, so validate in our
implementation as well in debug builds. This can also help with fuzzing
efforts.

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

This benchmark renders a single triangle to a double-buffered swapchain.
It uses a passthrough vertex and fragment shader written in GLSL and
compiled into SPIR-V using glslang.

Bug: b/158231104
Change-Id: I21f00f8f8595e018ff0d05f5af898a1f64d4dd12
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45629
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Note glslang's build targets may already have been added by the PowerVR
SDK. In that case, we use their copy. This is not optimal since it
potentially makes our test results depend on whether or not building the
PowerVR samples has been enabled, but it prevents duplicate targets.

Bug: b/158655757
Change-Id: Ic4e9292da9b1bb498164929cc7f93e73bf1fd6e6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45628
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>

This will be used by benchmarks and unit tests.

Bug: b/158655757
Change-Id: Idca9f31be946dc3209b8c93cd2195dd43b1e4233
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45649
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>

This refactoring is part of a hack which will allow us to add glslang
for use by unit tests and benchmarks, but skip it when PowerVR already
provides glslang.

Bug: b/158655757
Change-Id: I1991ea5ea7524ba71ce9bc2c1d55114318ba434f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45648
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>

vkCmdClearColorImage() and vkCmdClearDepthStencilImage() are currently
implemented using Blitter::clear(), which delegates to fastClear() for
certain formats, or falls back to using a generic Reactor routine.

This change benchmarks the performance for:
 - VK_FORMAT_R8G8B8A8_UNORM (fast path)
 - VK_FORMAT_R32_SFLOAT (slow path)
 - VK_FORMAT_D32_SFLOAT (slow path)

Bug: b/158231104
Change-Id: I5383b322e3ea5de6b21113843fb665a22a92b9bf
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45470
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>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Using https://github.com/KhronosGroup/Vulkan-Headers at tag v1.2.141.

Vulkan-Hpp is useful for writing unit tests and microbenchmarks, since
it includes support for loading a specific dynamically linked library:
https://github.com/KhronosGroup/Vulkan-Hpp#extensions--per-device-function-pointers

It also provides some abstraction to make tests more succinct and less
bug prone.

Bug: b/144696871
Change-Id: I4b22aefd205c01094e525b051b088ea9df14cca8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45568
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>

In 34c59c9b ("Update Vulkan headers to version 1.1.111") the Vulkan
Headers were inadvertently converted to CRLF line endings, convert
them back.

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

Bug: b/157926124
Change-Id: Iba985aa82cbda2d2d9778909d47abda2f0a7322b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45489
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ari Suonpää <ari.suonpaa@siru.fi>

Bug: b/155664177
Change-Id: I9322be202434908dfd652980f50e1024cf2efa2d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45368
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Trevor Black <vantablack@google.com>
Presubmit-Ready: Trevor Black <vantablack@google.com>

`marl::Scheduler::setWorkerThreadCount()` and `marl::Scheduler::setThreadInitializer()` have been deprecated.
`marl::Scheduler::Config` is the new API.

See https://github.com/google/marl/issues/139 for context.

Bug: b/140546382
Change-Id: Ida768eea98a7ca5d22f55f5055ca288b41b353d0
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45493Tested-by: Ben Clayton <bclayton@google.com>
Presubmit-Ready: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Bug: b/152339534
Change-Id: Icfbd4d3a00ffb322d083dccd7aee980ae1ee91d6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43109Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

* changes:
  Update Marl to 38c0c7a0f
  Squashed 'third_party/marl/' changes from 3c643dd4c..38c0c7a0f
  Fix LLVM_VERSION_MAJOR for LLVM 10 on macOS

Changes:
    38c0c7a0f Add Scheduler::Config and deprecate old [gs]etters
    17b12a448 Use CreateFiberEx instead of CreateFiber (#141)
    7236bd098 Test build / warning fixes for iOS
    c716869a7 Enable FreeBSD support
    00433d418 Add tests for using a marl::Scheduler without binding
    6b4f6472e Fix CMake warning when not built as subproject
    0591f0ef0 Kokoro Ubuntu: Switch to docker image
    bf9255db7 Optimization for marl::parallelize

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

Bug: b/140546382
Change-Id: I5eaceebcbfef7636fd711d9e4dc7ae4a946e8a34

38c0c7a0f Add Scheduler::Config and deprecate old [gs]etters
17b12a448 Use CreateFiberEx instead of CreateFiber (#141)
7236bd098 Test build / warning fixes for iOS
c716869a7 Enable FreeBSD support
00433d418 Add tests for using a marl::Scheduler without binding
6b4f6472e Fix CMake warning when not built as subproject
0591f0ef0 Kokoro Ubuntu: Switch to docker image
bf9255db7 Optimization for marl::parallelize

git-subtree-dir: third_party/marl
git-subtree-split: 38c0c7a0fb1ceec42fb48d9c5380026a9eb9b076

Looks like I generated the configs using ToT which had already bumped version, insteaad of the snapshot held by SwiftShader `third_party/llvm-10.0`

Bug: b/152339534
Change-Id: I7d01a3c8d308916c6fa699ba73f0b3201fdf1658

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

Using headers from https://github.com/KhronosGroup/Vulkan-Headers at
tag v1.2.141.

* Modified vulkan.h to still include vulkan_fuchsia_extras.h like
  before.

* VK_NVX_device_generated_commands was replaced with a
  non-experimental version VK_NV_device_generated_commands.
  So replaced the symbols in VkStringify too.

* Preserved the line endings of the existing files.

* Note that VK_PIPELINE_BIND_POINT_RANGE_SIZE doesn't include the Ray
  Tracing pipeline bind point.  This is fine since it is not supported
  by SwiftShader.

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