Eventually, this should probably be fetched from the
gralloc buffer metadata using
Gralloc4::Get(android::gralloc4::MetadataType_Dataspace)

Bug: b/147316305
Bug: b/175132241
Test: launch Cuttlefish w/ SwANGLE
Test: cts -m CtsGraphicsTestCases -t
      MediaVulkanGpuTest#testMediaImportAndRendering
Change-Id: Ie991380d2d27e7a540ffe37cfc81109618f2d507
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51688
Presubmit-Ready: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>

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

When the homogeneous w coordinate is near 0, the projected x or y
coordinates (after viewport and subpixel scaling) may be larger than
what's representable by 32-bit signed integers. On x86 this produces
the "indefinite" integer value 0x80000000. This negative value is
returned even for positive inputs. This causes the back-face culling
calculations to reject triangles which are in fact visible.

This change addresses that by introducing the rr::RoundIntClamped()
function, which guarantees that very large positive floating-point
values are converted to a positive integer value near INT_MAX.

Note that the Vulkan spec states that "[the determination whether the
triangle is back-facing or front-facing] is made based on the sign of
the (clipped or unclipped) polygon’s area computed in framebuffer
coordinates." Thus the alternative of performing culling using the
unprojected coordinates would have to take negative viewport dimensions
into account, and may not produce the same results as sub-pixel
snapped coordinates.

Adjust back-face culling of wireframe triangles to use the same
calculations as solid triangles.

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

Members of classes that are declared as static constexpr are not defined
as part of their declaration. Thus they must be defined elsewhere. And
they can't be defined in the header file, or there will be multiple
definitions for each file that includes the header.

So define these contexprs in Constants.cpp

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

This extension allows the host to reset query pools without the use of
vkCmdResetQueryPool.

Bug: b/169602655
Tests: dEQP-VK.query_pool.occlusion_query.*
Change-Id: I20a121d30ff5c39dc9df0a803c3f054ff217e5dc
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51309
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

This extension allows users to query and specify different usages for
the main image and the stencil. SwiftShader does not use an image's
usage for non-debug purposes outside of
vkGetPhysicalDeviceImageFormatProperties2. This applies to separate
stencil usage as well.

Bug: b/176098507
Tests: dEQP-VK.pipeline.sampler.separate_stencil_usage.*
Tests: dEQP-VK.renderpass.suballocation.multisample.separate_stencil_usage.*
Tests: dEQP-VK.renderpass2.suballocation.multisample.separate_stencil_usage.*
Change-Id: Iea74a9fa0de8cdcc51bdc613cdc0754e0f327fd5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51368Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

It only contained the now trivial OpcodeName() implementation. Since the
SpirvShaderInstructions.cpp file already contains other SPIR-V opcode
utility functions, move it there.

Also make this function return a pointer to a constant char string,
to avoid needless std::string construction.

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

It's only used for compilation, so don't hang on to it for the entire
lifetime of the routine. Likewise the dylib reference can be local.

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

It's only used for mangling the names of our generated functions during
Routine construction, so don't hang on to it for the entire lifetime of
the routine.

Also, don't set Function attributes during routine compilation, set them
at creation.

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

The LLVMContext object is used for caching LLVM types, eliminating
duplicate constants, and things like handling diagnostics information.
Previously we created one for the JITBuilder as well as the JITRoutine.
While having multiple ones is mostly benign from a correctness point of
view, it adds unnecessary overhead.

This change reuses the context created for the JITBuilder object (which
is used during IR construction), for the JITRoutine (which uses it for
actual compilation).

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

Clang 9 escalates a warning about an unsigned integer being compared
against a signed integer into an error.

Fixed by making an integer literal be unsigned.

Bug: b/152777669
Change-Id: I38c61ac0837f756c73b8664f7774719a94353fac
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51530Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Produced by Clang 10's -Wmissing-field-initializers.

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

Bug: b/176909700
Change-Id: I5cecfbdfc4b5fc28180b1421c36ce94813605bd5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51508
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Caramelli <caramelli.devel@gmail.com>
Commit-Queue: Nicolas Caramelli <caramelli.devel@gmail.com>

While SwiftShader does not support this extension, it is core in Vulkan
1.2. So we must properly process the structures it adds.

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

Clang 10's -Wimplicit-int-float-conversion complains that
MAX = 2147483647 cannot be exactly represented as a float.

Use an explicit conversion to suppress the warning locally. Note that
this value's usage to produce a random boolean doesn't critically depend
on exact conversion.

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

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

VkPhysicalDeviceVulkan12Properties was added to the core spec by Vulkan
1.2. It allows users to query the following properties simultaneously:
    * VkPhysicalDeviceDriverProperties
    * VkPhysicalDeviceFloatControlsProperties
    * VkPhysicalDeviceDescriptorIndexingProperties
    * VkPhysicalDeviceDepthStencilResolveProperties
    * VkPhysicalDeviceSamplerFilterMinmaxProperties
    * VkPhysicalDeviceTimelineSemaphoreProperties
    * and framebufferIntegerColorSampleCounts

All these structs are a part of the core spec and must be supported.

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

This change deprecates rr::RcpSqrt_pp with rr::RcpSqrt. As with Rcp,
RcpSqrt computes the result using Newton-Rhapson if it's faster and the
initial approximation intrinsic is available on the current target.
Currently, only LLVM on Intel will use NR for RelaxedPrecision. Note
that passing in Precision::Relaxed will produce a faster, but less
precise reciprocal sqrt.

Also made it so that SprivShader instruction GLSLstd450InverseSqrt now
invokes RcpSqrt(x, Precision::Full) instead of performing 1/sqrt(x).
Note that the Vulkan spec states that inversesqrt()'s precision is 2
ULP, and sqrt()'s precision is inherited from 1.0 / inversesqrt();
however, our rr::Sqrt is implemented in terms of x86's sqrt intrinsic on
x86, or as calls to sqrt from Math.h.

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

This change deprecates rr::Rcp_pp with rr::Rcp, which makes sure to
correctly compute the reciprocal using the Newton-Rhapson refinement
only if the current target supports the required instrinsic, otherwise
using 1 / x. Currently, only LLVM on Intel will use NR. Note that
passing in Precision::Relaxed will produce a faster, but less precise
reciprocal.

Also removed PixelProgram::linearToSRGB as it's unused.

Bug: b/169760262
Bug: b/149574741
Change-Id: I4a2f943aa60116c4397d7a8ae18583a260824788
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50648Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>

ReactorBenchmarks.cpp was accidentally moved to the wrong location as
part of swiftshader-cl/50388.

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

These were used by older versions of the Android CTS and are no longer
present in dEQP.

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

VkBuffers backed by AHBs do not require dedicated allocations.
As such, update SupportsAllocateInfo() to report supported as
long as a VkImportAndroidHardwareBufferInfoANDROID or a
VkExportMemoryAllocateInfo with AHB bit was found.

Updates allocateAndroidHardwareBuffer() to treat the lack of a
dedicated buffer or image as a request to allocate a blob AHB.

Bug: b/147316305
Bug: b/169796031
Test: cts -m CtsNativeHardwareTestCases
Test: cts -m CtsDeqpTestCases -t
  dEQP-VK.api.external.memory.android_hardware_buffer.*
Change-Id: Ica2782b4570bd4d4c1e5585b696b40314a267b2f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51248
Presubmit-Ready: Jason Macnak <natsu@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

UniformBufferStandardLayout changes the alignment rules for uniform
buffers. This doesn't change SwiftShader's behavior, and is treated as
always enabled for the purposes of validating inputs to SPIRV-Tools.

Bug: b/169604082
Tests: dEQP-VK.ubo.*
Change-Id: I0ec59ceb0bf6cc487f37e292a04e875268c37185
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/49868Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Remove the requirement that Subzero must not diverge from the upstream
repo.

Recommend using the MAKE_BUILD_PARALLEL_LEVEL environment variable to
change the default parallelism.

Fixes: b/166244497
Fixes: b/170565506
Change-Id: I00029e392282edd650712f031079073482365af3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51188
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

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

This is the revision where the newly created 1.2.5 version is merged
back into the master branch.

Revision https://github.com/KhronosGroup/VK-GL-CTS/commit/41331850eb212df08e010b4d861992fe0aae622264676f3ed52018f0959e00aff3976cf65fe8d1fc
Branch https://github.com/KhronosGroup/VK-GL-CTS/tree/master

Notable new tests:
- Enable random writes for storage images (https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/1973)
- Add tests for oob access in unexecuted shader paths (https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2171)
- Add array of images copy tests (https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2452)
- Add tests for clamping of depth values (https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2312)
- Add cube compat. to array image copy tests (https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2542)
- Tests for pipeline layout early destroy (https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2362)

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

This extension is relied on by dEQP-VK.robustness.image_robustness.*
but it is only checked for since dEQP 1.2.5.

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

The last element of sw::Constants::maxPos was inadvertently 0x7F7FFFFE
instead of 0x7F7FFFFF. Replace it with a scalar which is broadcast to
all elements within Reactor code.

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

Validation is costly and it's the applications' responsibility to send
valid SPIR-V to the ICD, so we shouldn't do it in Release builds.

Note that while in Debug builds we already perform validation during
creation of the shader module (to catch issues even sooner), we should
validate again during pipeline compilation to ensure we (or the tooling
we use) didn't alter the SPIR-V to become invalid.

Bug: b/158228522
Change-Id: I5b8153f0397c609d139e37909868b5836d57d40e
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51168Reviewed-by: Sean Risser <srisser@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

These were implemented using 64-bit and 128-bit accesses, respectively,
and thus cause both alignment and overflow issues. We weren't exposing
support for them, so they can be removed for now instead of requiring
an implementation which doesn't have these flaws.

According to https://vulkan.gpuinfo.org/listformats.php, R16G16B16 is
very rarely supported as an image format (but as a buffer format it is
fairly common). R32G32B32 is very widely supported actually, due to
being mandatory for Direct3D 10:
https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/format-support-for-direct3d-feature-level-10-0-hardware#dxgi_format_r32g32b32_typelesspcs-5

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

Also fix clamping of the smallest negative value to -1.0.
See https://www.khronos.org/registry/vulkan/specs/1.1/html/vkspec.html#fundamentals-fixedfpconv

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

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

When all three vertices of a triangle have depth 0, the maximum exponent
e is 0. We can't just use (e - n) << n as the bit pattern for 2^(e - n),
because the exponent field underflows and creates a negative value.

All triangles where all depth values have a bias-adjusted exponent less
than 23 have this issue (note 2^(23 - 127) = 4.9e-32).

The fix is to perform 2^(e - n) as 2^e * 2^(-n). The multiplication
handles the underflow of the exponent either by creating a subnormal, or
zero.

Bug: b/139341727
Change-Id: I44b87feb55f61c5fa18ba235e9ec211926de3b3e
Fixes: b/174051829
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51148
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Commit-Queue: Nicolas Capens <nicolascapens@google.com>

Reactor backend: Subzero

Change-Id: I033790ccc4d88a4cf5acc96bd90a94f6cc8ebdc4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51089Tested-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>

Cherry now runs out of memory when using 32-bit Go. The 64-bit version
of Go requires a 64-bit version of GCC, which comes with MinGW-W64.
See also https://android.googlesource.com/platform/external/cherry/+/9592629522babac1fb1a337433ae27f78f696703/README#29

dEQP's Python scripts have been updated to require Python 3.

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

Overview of the changes:

The Context class has been split into more Vulkan related functional
elements:
- The IndexBuffer class, which contains the index buffer information
  and has been extended to also the functionality to support
  primitive restart. Should we need primitive restart related caching
  in the future, this would be the place to do it.
- The Attachments class, which contains information about render
  targets and depth and stencil buffers
- The Inputs class, which contains information about descriptor sets
  and input streams.
- The GraphicsState is a completely constant class which can only be
  modified in the constructor, which represents the state of a
  graphics pipeline, which never changes past construction. The
  GraphicsState can be combined with a DynamicState structure in
  order to create a complete state used by rendering.

Also to note:
- The DynamicState class in now in Context.hpp, in order for the
  GraphicsState to have functionality related to it.
- PushConstantStorage was moved to vk::Pipeline, as it is used by
  both the Graphics Pipeline and the Compute Pipeline.
- Viewport/scissor functionality is contained in the GraphicsState
  and was removed from the Renderer.
- All *Processor::update() functions now receive only the information
  that they require, rather that having access to the entire context.

Bug: b/132280877

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

... to make VkAHardwareBufferImage::init() happy.

Bug: b/147316305
Bug: b/141698760
Test: cts CtsGraphicsTestCases -t android.graphics.cts.BasicVulkanGpuTest
Change-Id: I599e2c0803a4008b80c1cd1f3ba9e4198cd0b72d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51069Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

... as it does not have an equivalent format in the
AHardwareBuffer Format Equivalence table in the Vulkan spec.

(Note: AHARDWAREBUFFER_FORMAT_Y8Cb8Cr8_420 format handling
needs to be updated as we currently assume a 3 plane layout)

Bug: b/175132241
Test: launch Cuttlefish w/ SwANGLE and open Camera
Change-Id: I2ac6a9937b2fd75f559d654f1e179ea5bcfa456f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51051
Presubmit-Ready: Jason Macnak <natsu@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Bug: b/147316305
Test: launch Cuttlefish w/ SwANGLE and open Youtube
Change-Id: Ife9f4c906d2b4af86060c11d8338ce8b65d8439f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51068
Presubmit-Ready: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>

SPIR-V 1.4 is coupled with Vulkan 1.2 to introduce a core extension
that exposes float controls and new OpExecutionMode arguments for
controlling floating point behavior. Those Execution Modes are only
legal if the implementation says it supports them in the
FloatControlsProperties struct. SPIR-V 1.4 also adds some operands
and a few new opcodes.

This version update tells SPIR-V tools to allow behavior created to
support version 1.4, like uniform buffer standard packing. It also
exposes the Vulkan extension for SPIR-V 1.4.

Bug: b/173046235
Tests: dEQP-VK.*
Change-Id: I4bb387fd7ba4695babff3edbcaabca583c4fdde1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50228Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>