This function reports on a Vulkan driver's fine grained capabilities.
A previous change broke some functionality in ANGLE. This is an update
to that reverted patch.

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

Previously Image::getMipLevelExtent() was the only way to retrieve the
extent of an image, which didn't make sense for images for which we're
not accessing the mipmaps, like framebuffer attachments. A getExtent()
method was added for these cases where we only need the full extent.

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

Image views are only accessed by shaders, and we've previously ensured
descriptors only have one field for holding either the depth of a 3D
texture or the array layer count. This value is accessed through the
getDepthOrLayerCount() method, and so the getMipLevelExtent() of the
ImageView class only has to return the 2D extent.

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

OpImageQuerySize[Lod] SPIR-V instructions were previously implemented
by storing both the image depth and layer count in the descriptor. Since
3D textures can't be arrayed, we only need one field. Also avoid the
division by 6 for cube array layers in the instruction implementation,
by performing it during the descriptor update instead.

This reflects a similar change made by
https://swiftshader-review.googlesource.com/c/SwiftShader/+/47388

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

This reverts commit 44e1791f.

Reason for revert: Broke ANGLE, need to patch

Change-Id: I98cb807b0e18bf7df2d9ba51893d65ad5a8eba6d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47890Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Sean Risser <srisser@google.com>

We're making a new config in the Chromium project for Linux builds -
USE_X11 && USE_OZONE. The idea of that is to ease migration
from non-Ozone/X11 to Ozone. It will be possible to choose between
Ozone and non-Ozone path on runtime by supplying
the --enable-features=UseOzonePlatform flag.

However, SwiftShader doesn't support such a build and always uses
FrameBufferOzone. This is not correct when the browser is
run without the Ozone feature enabled aka using old
non-Ozone/X11 path. Basically, it results in crashes
during swap buffers call.

The very naive solution is to try to test the display. If we
can cast it to XDisplay and its valid, use X11 framebuffer.
Otherwise, use Ozone. Though, I'm not 100% sure about the safiness
of this check. Thus, we must be careful about that.

This is one of the last patches that blocks enabling both
use_x11 && use_ozone in Chromium.

Bug: chromium:1119303
Change-Id: I969798abd4d0bbacaffb7704161eac38e77d9311
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47868Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Maksim Sisov <msisov@igalia.com>

Previously we were checking whether all attachments have a format which
requires clamping. We now support the independentBlend feature, and
independent clamping, so we can optimize the blend state more granularly
and not miss opportunities.

Bug: b/140193782
Change-Id: I7e663fd8ebc6a7a6e35133c0c4c5cad84278eeb3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47828
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 function reports on fine-grained Vulkan features and extensions.

Bug: b/162404391
Change-Id: Ifbb423a6fcb9134801eed112117a602f231e6685
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47349Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Sean Risser <srisser@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

The cfi bot is throwing an error because an object is being assigned
with memory containing an invalid vtable. This is caused by assigning
a chunk of memory to an object before calling placement new using that
memory.

This cl assigns the pointer after the object has been constructed to
avoid triggering this error.

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

Change-Id: Icd01356c6bfaf644112a6ca9cb92b8fc62be5291
Bug: b/149490161
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47769Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

LLVM 11 deprecates the default boolean parameter which indicates whether
vector types are variable-length. Explicitly pass 'false'.

LLVM 11 introduces a FixedVectorType for this as well, which would help
readability, but we're still at LLVM 10.

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

Reactor backend: Subzero

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

This fixes a bug in the descriptor data where the sample pitch was set
to the layer pitch for array images (it should always be the slice
pitch), and the descriptor's slice pitch (which stores the layer pitch
in case of array images), was taking the sample count into account
twice.

Note that while the image robustness extensions still allow read
operations to return undefined values "if only the sample index was
invalid", so clamping that value would suffice (as currently done in our
OpImageFetch implementation), write operations always have to be no-op.
This change also 'nullifies' the OpImageRead instructions for invalid
sample indices.

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

Cubemap textures are created with a border, which means that their
size is larger. Their range is also different. Instead of [0, dim-1],
they have a [-1, dim] range. This means that if we copy them starting
at [0, 0] for their full size, we'll overflow at the end, since the
buffer starts at [-1, -1]. This cl prevents going through the fast
copy path when we have a border.

Bug: chromium:1115345
Change-Id: I333acfd6094645231eb111634359d82ed3d5c787
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47668
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Reactor backend: Subzero

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

Block members were getting decorations applied from all previous
block members. For example, in this case:
in InterfaceBlock {
 layout(location = 0) in vec4 in_color_smooth;
 layout(location = 1) in flat vec4 in_color_flat;
 layout(location = 2) in noperspective vec4 in_color_noperspective;
 layout(location = 3) in centroid vec4 in_color_centroid;
}

- the member at location 2 would get decorated with both flat and
  noperspective
- the member at location 3 would get decorated with both flat,
  noperspective and centroid

I added a local variable for the member decorations in order to not
bleed information between block members.

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

With the assertion for these tests fixed here:
https://gerrit.khronos.org/#/c/6075/

The *.too_many test passed locally, but not the *.too_many_timeout
test. The reason is that, when a timeout is provided, the acceptable
return value for failing to acquire an image is VK_TIMEOUT, not
VK_NOT_READY. Returning VK_TIMEOUT when a timeout is provided solves
the issue.

Bug: b/162249856
Change-Id: Id2733fec8422aad93a1aa351b481691c69692168
Tests: dEQP-VK.wsi.*.swapchain.acquire.*
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47648
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>

This extension allows the viewport's minimum and maximum depth to be
outside of the 0.0 to 1.0 range:
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_depth_range_unrestricted.html

Note that while most extensions don't change the behavior of the logical
device whether they're enabled or not (since they just allow new calls,
enums, or values which are otherwise undefined behavior and implementing
the functionality of the extension is valid as "undefined" behavior),
enabling/disabling this extension does cause an observable difference.

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

This cl adds a verification before using the imageView stored
within descriptor sets to make sure they still exist. These
imageView objects are used to make sure images which require
preprocessing (cubemaps and compressed images) are up to date.

The device contains the list of active ImageView objects.

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

Reactor backend: LLVM

Change-Id: I2bd569ebb5f74fd708e5d0f9598be1f6d445b863
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47468Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

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

1D images were being treated as 2D ones with the second coordinate set
to 0.0. It required other workarounds like moving the array layer
coordinate and providing an addressing mode for the second coordinate.
These have been removed, and the texel address calculation now ignores
the second coordinate for 1D images.

Note this doesn't specialize filtering for the 1D case yet, so the
weights for filtering in the v-direction are explicitly zeroed out.

Fixes: b/162858741
Bug: b/134669567
Change-Id: I4684ee0337ac500860e9939087045a953bad813a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47428
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Instead of reusing the 2D mipmap LOD calculation, this change adds a
separate method for computing the LOD for 1D sampling operations.

This also revealed that we would perform the anisotropic filtering
calculations on 1D sampling operations if enabled, which makes no sense.
This change limits it to 2D sampling only.

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

The array layer coordinate isn't subject to addressing modes like the
other coordinates. There's just one selection computation:
 https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#textures-unnormalized-to-integer
This change eliminates the internally used ADDRESSING_LAYER mode, and
avoids using the 'w' coordinate as the array layer coordinate for 2D
array images (instead exclusively using it for 3D images).

Also, the cube face index is combined with the array layer in case of
cube array images. The division by 6 was eliminated by adjusting the
descriptor 'depth' field instead.

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

- Sort the coordinates and operands in the same order as for the SPIR-V
  instructions.
- Renamed 'q' to 'dRef'.
- Used integer type for offset operands.
- Renamed 'addressingModeY' to 'addressingModeA'. Note this is only used
  by cube array coordinates. 2D array coordinates use 'addressingModeW'
  at the moment.
- Removed array layer coordinate parameter from 3D sampling.
- Added 'dRef' operand for 3D sampling.

Bug: b/162315264
Change-Id: Ia24aa22a57ba5507aa4c8cf617f49f18ccca59c5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47097
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 ensures that if the sample or layer coordinate were not forced to
be in range but the 'valid' mask indicates whether they're in range,
we sample texel 0 instead of potentially outside the image memory.

Note this does not yet validate the sample coordinate.

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

Reactor backend: Subzero

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

I stumbled across this while bringing up the Chromium build
under Python3. The change should allow the code to work under
both 2 and 3 now.

Bug: chromium:1112479
Change-Id: I5ae0cafdd453a12b53a0fa5392ad46cba60f4ed4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47308Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

This extension was never actually implemented. While it has been
promoted to 'core' in Vulkan 1.1, the storageBuffer16BitAccess feature
bit indicates whether or not the implementation supports the
functionality.

Bug: b/162742397
Test: dEQP-VK.info.device_mandatory_features
Change-Id: I3e2871ce09975db3da2ad1f042d6955dbd565479
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47408
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

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

Reactor backend: Subzero

Change-Id: I25a37b74498d3a287ed8d78c6a16ca08c3973688
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47328Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Reactor backend: Subzero

Change-Id: I5d78eb4b823a056a07be57932c51391661d4f845
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47268Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

third_party/subzero is a fork which we are responsible for. Many of the
non-PC words were in files we actually have no use for, so they've been
removed altogether.

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

Swiftshader already counts all the fragments for this feature, it just
needed to be enabled in VkPhysicalDevice.cpp. The occlusion_query tests
that remain unsupported require VK_EXT_host_query_reset. This is
unsupported in SwiftShader as of now, though it is required for Vulkan
1.2 conformance.

Bug: b/148241855
Tests: dEQP-VK.query_pool.occlusion_query.*
Change-Id: Ib03df4225ed49865c648368ebf0547bfc3d117f7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47148Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>

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

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

Reactor backend: Subzero

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

Added a mask to prevent writing to unused outputs

Bug: b/162348737
Change-Id: I72b86cf2f6d0f9f07992cc63bc55fe9e45822e1d
Tests: dEQP-VK.draw.output_location.array.*
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47168
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

The feature is currently always enabled, so we ignore the creation flag
for now.

Bug: b/159329067
Tests: dEQP-VK.robustness.image_robustness.*
Change-Id: I5385196afd93e3deeaec5713f301af4fed4ef15e
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46828
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>

VK_EXT_image_robustness requires returning zero on out-of-bounds image
accesses. OpImageFetch was previously merely clamping the coordinates to
be in-bounds.

This change reuses some of the functionality for
VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER to perform texel replacement.

Bug: b/159329067
Tests: dEQP-VK.robustness.image_robustness.*
Change-Id: I8c00b8de2793b0b7028230cb180d308a4b9b60ec
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47095
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>