... to use AHardwareBuffer Usage Equivalence Table from
the spec.

Bug: b/169439421
Test: launch Cuttlefish with SwANGLE
Test: dEQP-VK.api.external.memory.android_hardware_buffer.*
Change-Id: Iad6bf6424a1139c623b0fc664b949eb40bbb11bb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53148
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>

This cl marks VK_KHR_xcb_surface as unsupported if we haven't
successfully loaded XCB. Also, an assert was added to make sure
vkCreateXcbSurfaceKHR is called with a valid connection.

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

This cl marks VK_KHR_xlib_surface as unsupported if we haven't
successfully loaded X11. Also, an assert was added to make sure
vkCreateXlibSurfaceKHR is called with a valid display.

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

This cl adds a mechanism so that extension strings can easily be
marked as supported or unsupported base on a boolean value determined
at runtime.

Bug: b/139491466
Change-Id: I4438a482c92d76025f137a7a77f61863abaae9c9
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53228
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>
Commit-Queue: Alexis Hétu <sugoi@google.com>

optimizeSingleBasicBlockLoadsStores() supersedes both
eliminateLoadsFollowingSingleStore() and
optimizeStoresInSingleBasicBlock().

This was verified by adding asserts the latter when the delete more
instructions. They're never hit by dEQP-VK tests. Only the
PointerToPointer triggers an assert. It goes away when running
optimizeSingleBasicBlockLoadsStores() twice. Since it is very rare to
store the address of a pointer in another pointer, and before the new
optimization pass was implemented we also did not handle this case,
we're not going to pay the cost of running it twice.

eliminateUnitializedLoads() was moved earlier because we never produce
new loads of uninitialized values in the optimization passes and it's
best to eliminate these allocas early.

The late eliminateDeadCode() was also removed since we already run it
at the end of optimizeSingleBasicBlockLoadsStores().

TODOs for cases where the load/store sizes don't match have been removed
because propagating a different type causes issues.

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

CMake's CMAKE_BUILD_TYPE variable is ignored for multi-config
generators,like Visual Studio. Instead, we must specify the config when
building.

For VulkanTester, needed to add "RelWithDebInfo" to search paths for
vk_swiftshader.dll as that's the "Release" config we use for Kokoro
builds.

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

Meant to use an "#if" not "#if defined" for USE_HEADLESS_SURFACE. Before
this fix, we would always request the headless surface extension, which
would usually fail on Windows if no loader is installed since current
GPU drivers don't implement this extension yet.

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

Also make the image not a solid color.

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

1D image sampling used to be treated as 2D image sampling with the
second coordinate being ignored. But a bug was causing us to use the
second component of the 'offset' parameter. This was worked around by
initializing all parameters provided to the sampling routine.

This costs some performance, and since we've fixed the 'offset' bug and
have specialized handling of 1D images now, the workaround can be
reverted.

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

When a store is propagated to all stores succeeding it in the same basic
block, and we encounter another store, we can delete the previous one.

This optimizes the StoresInMultipleBlocks test's generated code from:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         dword ptr [rsp],4
 mov         eax,4
 add         eax,3
 mov         dword ptr [rsp],eax
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret
a:
 mov         dword ptr [rsp],6
 mov         eax,6
 add         eax,5
 mov         dword ptr [rsp],eax
 jmp         b

Into:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         eax,4
 add         eax,3
 mov         dword ptr [rsp],eax
 jmp         b
a:
 mov         eax,6
 add         eax,5
 mov         dword ptr [rsp],eax
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret

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

For loads following stores in the same basic block, replace their result
with the data that was stored.

It transforms the output of the StoresInMultipleBlocks test from:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         dword ptr [rsp],4
 add         dword ptr [rsp],3
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret
a:
 mov         dword ptr [rsp],6
 add         dword ptr [rsp],5
 jmp         b

Into:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         dword ptr [rsp],4
 mov         eax,4
 add         eax,3
 mov         dword ptr [rsp],eax
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret
a:
 mov         dword ptr [rsp],6
 mov         eax,6
 add         eax,5
 mov         dword ptr [rsp],eax
 jmp         b

While at first this might seem like a regression, note that
`add [rsp],3` performs both a load and a store. The optimization pass
eliminated two load operations from this test. The redundant stores will
be eliminated by a subsequent change.

Also adds a unit test for the case where store-to-load propagation
should not be performed due to an indirect store through a pointer
happening in between.

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

Previously we would append the 'begin' basic block with the conditional
branch only once we know whether or not there's a 'false' block separate
from the 'end' block (namely when executing the Else statement). We can
instead treat the 'false' block as the 'end' block itself when no Else
is encountered and simply continue emitting instructions in this block.

Note this removes the need to explicitly materialize all variables,
because that's taken care of by createCondBr().

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

Materializing all variables should be done prior to actual branches, not
when changing the insert point. The only reason we did it in the latter
too was due to changing insert point before creating the branch for an
If statement.

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

This change implements the Scalar Replacement of Aggregates (SRoA)
optimization. Since Reactor only supports array aggregates, this
replaces arrays which are only indexed by static indices with individual
variables for each element.

The ReactorArray test is optimized from:

 sub         rsp,38h
 mov         dword ptr [rsp],1
 mov         dword ptr [rsp+4],2
 mov         eax,dword ptr [rsp]
 mov         ecx,dword ptr [rsp+4]
 mov         dword ptr [rsp],ecx
 mov         dword ptr [rsp+4],eax
 mov         eax,dword ptr [rsp+4]
 add         eax,dword ptr [rsp]
 add         rsp,38h
 ret

Into:

 sub         rsp,20h
 mov         eax,2
 add         eax,1
 add         rsp,20h
 ret

Which is identical to the CArray test's generated code.

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

This change adds a callback mechanism to report how many instructions
of certain types are left after the optimization passes have been run.
This enables unit tests to check that the desired optimization actually
took place, instead of just checking correct execution results.

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

x86-64 does not support 64-bit immediates as absolute memory addresses.
They have to be stored in a register, which can then be used as [base].

Previously we addressed this at the SubzeroReactor level by emitting a
Bitcast from an Ice::Operand to an Ice::Variable, for which Subzero
already supported 64-bit constants as input.

This change implements X86OperandMem creation from a 64-bit constant
operand by letting legalize() move it into a GPR and using it as the
memory operand's base register.

A Reactor unit test is added to exercise this.

Another issue was that doLoadOpt() assumed all load instructions are
candidates for fusing into a subsequent instruction which takes the
result of the load. This isn't true when for 64-bit constant addresses
an instruction to copy it into a register is inserted.

For now this case is simply skipped. A future optimization could adjust
the iterators properly so the load from [base] can be fused with the
next instruction.

Lastly, it is possible for a 64-bit constant to fit within a 32-bit
immediate, in which case legalize() by default does not perform the copy
into a GPR (note this is to allow moves and calls with 64-bit
immediates, where they are legal), and simply returns the 64-bit
constant. So we must not allow legalization to an immediate in this
case. Note that while we could replace it with a 32-bit constant, it's
rare for absolute addresses to fit in this range, and it would be
non-deterministic which path is taken, so for consistency we don't
perform this optimization.

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

SwiftShader has no use for this since shader execution with robustness
features enabled can not access memory outside of the graphics
resources. For Chromium it also runs in the GPU process, which isolates
it from browser-wide and even tab renderer data and code, and also has
its own sandboxing.

If we ever do need randomization to prevent attacks, and project Bunker
doesn't provide the needed site isolation, it should be implemented
either at the Reactor level or as separate transformation passes where
possible.

While previously this feature was already disabled, there might have
been inadvertent randomization which could explain our test time
variability. It may also improve code generation performance a bit to
not have this code around any more.

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

When vkGetPhysicalDeviceSurfaceCapabilitiesKHR is called, we now return
VK_ERROR_SURFACE_LOST_KHR on Windows if the window handle (hwnd) is no
longer valid.

The assert was being tripped by Chromium's compositor_unittests for test
LayerWithRealCompositorTest.BackgroundBlur. With this fix, instead of an
assert, the test now fails because eglQuerySurface fails with
EGL_BAD_SURFACE.

Bug: chromium:1174372
Change-Id: I71164c30bddaa41753472389e996cebbff7fbf77
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52928Tested-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>

SPV_ENV_Vulkan_1_2 denotes support for all SPIR-V versions that are core
in Vulkan 1.2. This includes 1.4 and 1.5.

Tests: dEQP-VK.*
Bug: b/173046235
Change-Id: I7482d1bff6bf3b2c2291538517f6640647ab644c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50670Tested-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>

Rather than assume success, allow WSI surface implementations to return
a VkResult for getSurfaceCapabilities.

Also, made VkSurfaceKHR::getSurfaceCapabilities pure virtual, and moved
its implementation to a protected static helper named
setCommonSurfaceCapabilities.

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

We have fixed the original problem requiring the revert.

This reverts commit ed7c4d5c.

Bug: b/171498948
Change-Id: I02afbf9df677f6b691d0929a1f577ff355ef08e8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52668Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Presubmit-Ready: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>

Optimizer::eliminateLoadsFollowingSingleStore() was only looking at a
single instruction following the store.

Subzero derives Ice::Inst from llvm::ilist_node<Inst>, making it a node
in a circular linked list. However, we can't iterate until the end
because by default ilist_node<> does not provide sentinel node tracking.
If the llvm::ilist_node<Inst, llvm::ilist_sentinel_tracking<true>> class
is used instead, we can use isSentinel(), but this comes at the cost of
each node itself having to indicate whether it's the sentinel, and
keeping that up to date.

This change instead obtains the basic block's instruction list from the
store instruction, to get the iterator of the end node.

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

Pointers to the base address of arrays often get stored and then loaded
multiple time. This change adds an optimization pass to replace these
loads with the result of the alloca of the array, and eliminates the
allocas of the pointer variables.

The PropagateAlloca unit test without this optimization produces:

 sub         rsp,38h
 mov         dword ptr [rsp+8],16h
 cmp         ecx,0
 je          000002543C4E407E
 lea         rax,[rsp+8]
 mov         qword ptr [rsp],rax
 mov         rax,qword ptr [rsp]
 mov         eax,dword ptr [rax]
 add         rsp,38h
 ret

With the optimization pass it becomes:

 sub         rsp,38h
 mov         dword ptr [rsp],16h
 cmp         ecx,0
 jne         0000015DC3B33074
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret

Also add a couple of unit tests for corner cases where the propagation
is not safe to perform.

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

These cases were discovered through various attempts to elide more loads
and stores after a branch has already occurred.

Also implement operator!= for Pointer<T>, and remove the redundant
Nucleus:createPtrEQ() which both LLVM and Subzero support through
integer value comparison.

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

Prior to supporting MemorySanitizer instrumentation of Reactor routines,
false positives in C++ code were avoided by marking all memory that was
written to by the Reactor routines as unpoisoned.

Now this can be disabled to avoid false negatives, i.e. uses of
uninitialized data either in the Reactor routine or originating from it.

REACTOR_ENABLE_MEMORY_SANITIZER_INSTRUMENTATION controls whether we get
the new behavior or the old unpoisoning.

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

Bug: b/180494886
Change-Id: Ib1ddebce8a5679af46a4c8457373f66289df03e7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52909Tested-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>

Reactor backend: Subzero

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

In DEBUG builds, enable validation layers: VK_LAYER_KHRONOS_validation
and VK_LAYER_LUNARG_standard_validation. Also register the debug utils
messenger ext callback for when validation layers report a problem. We
can force validation layers in non-DEBUG by defining
ENABLE_VALIDATION_LAYERS to 1.

In order to be able to use validation layers, load the Vulkan driver via
ICD, rather than directly. To load SwiftShader, generate a temp icd.json
file pointing at the driver path, and temporarily set the
VK_ICD_FILENAMES env var to point at it when we load the ICD. This also
allows us to load the native GPU driver by defining LOAD_NATIVE_DRIVER
to 1 (default is 0).

Fixed errors reported by enabling validation layers:
* TriangleSampleTexture had a mismatched binding number for the sampler2D
* Correctly set memoryTypeIndex for allocations instead of 0

Bug: b/176981107
Change-Id: I3c791086acea048b73d3568d6d7a45d8e0100c17
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52749
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>

These structures were zero-initialized to work around MSan false-
positives. Now that Reactor routines can be instrumented, we can omit
the initialization and detect whether they are properly set by the
normal code paths.

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

Reactor backend: Subzero

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

When using push constants, we end up having dynamic offsets on the
input parameter of the interpolation functions, so we need to be able
to handle this case. Since this is for push constants, we assume that
all dynamic offsets will be the same, for simplicity.

Bug: b/171415086
Change-Id: I5de1720e383c234c9392421d507a66e6d7ba2445
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52930
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>
Commit-Queue: Alexis Hétu <sugoi@google.com>

The Skia GPU MSAN bot runs >9 hours with this option set and
had to be disabled. We'd like to get test MSAN coverage for the
rest of Skia GPU and turn the bot back on, but need this option.

Change-Id: I1536912e9cfe35c294e750fcd4a1f515209989bc
Bug: b/155148722
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52908
Presubmit-Ready: Adlai Holler <adlai@google.com>
Tested-by: Adlai Holler <adlai@google.com>
Commit-Queue: Adlai Holler <adlai@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Using a memfd name to annotate swiftshader_jit allocations is quite
clever, but it doesn't work on Android because memfds can be shared
and so writing to mappings of them promotes CoW/shared, which is
classified by selinux as 'execmod' permission. Android prohibits
'execmod' permission for new app processes, because this is usually a
sign the app relies on shared text relocations, which are insecure. In
this case, that isn't actually happening, but we are subject to the
same blanket ban :)

Fortunately, Android has a longtime non-upstreamed prctl() to allow
private mappings to be named as well, PR_SET_VMA_ANON_NAME. As this
isn't generally available for Linux, wrap it in checks for __ANDROID__.

This enables the naming without tripping the 'execmod' permission check.

Bug: b/171498948
Bug: b/174801963
Change-Id: Ic4375bc4407e21ecdafb42a7cec651dc3b2ad13e
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52669Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Jason Macnak <natsu@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>

Bug: chromium:1113033
Change-Id: If878e7dfc9b2e1c54f7926f9d1a9af56c5bb5515
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52548
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Gavin Mak <gavinmak@google.com>
Commit-Queue: Gavin Mak <gavinmak@google.com>

[XLA:CPU] Remove uses of deprecated CreateAlignedLoad/Store builders

These are being removed in https://github.com/llvm/llvm-project/commit/f515ca8995ce3695c6e92d83ffca2012dc753bb3

Upstreaming original change made by Alexander Kornienko (alexfh@google.com)

Bug: none
Change-Id: I1b1553308cc40c7e99508fb5e3999e16049a8884
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52868
Presubmit-Ready: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>

This cl enables the sampleRateShading feature.

New test failures caused by enabling sampleRateShading:
Tests: dEQP-VK.glsl.builtin_var.fragdepth.*

List of affected tests now passing:
Tests: dEQP-VK.glsl.builtin_var.fragcoord_msaa.*
Tests: dEQP-VK.pipeline.multisample.min_sample_shading.*.samples_4.*
Tests: dEQP-VK.pipeline.multisample.mixed_count.*
Tests: dEQP-VK.pipeline.multisample.variable_rate.*
Tests: dEQP-VK.pipeline.multisample_interpolation.*.samples_4
Tests: dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_single_sample.*.samples_1
Tests: dEQP-VK.pipeline.multisample_shader_builtin.*.samples_4
Tests: dEQP-VK.pipeline.multisample_shader_builtin.write_sample_mask.*
Tests: dEQP-VK.renderpass.suballocation.sampleread.numsamples_4.*
Tests: dEQP-VK.renderpass2.suballocation.sampleread.numsamples_4.*

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

We explicitly call Driver::unload, but so does the dtor. We just needed
to clear the dll member after unloading.

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

I implemented this extension as part of swiftshader-cl/51589 but had not
exposed it as a supported extension. This worked fine when loading
SwiftShader directly, but I need to now load it via the loader.

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

Vulkan 1.2 added VkPhysicalDeviceVulkan11Properties, which allows users
to query support for several other device properties all together. We
can use templated static functions to make sure these properties are
only ever set in one place, similar to what we do for device features.

The only struct this doesn't work for is
VkPhysicalDeviceSubgroupProperties, because the names in that struct
and the Vulkan11 struct differ. So the Vulkan11 struct manually copies
the data from the getProperties(*) function for the subgroup properties.

Bug: b/176248217
Change-Id: I30e9e05ecbdb9a40fc3a59df6bd9b8ab9022c9fc
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51388Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Commit-Queue: Sean Risser <srisser@google.com>

This cl adds an implementation for:
- GLSLstd450InterpolateAtCentroid
- GLSLstd450InterpolateAtSample
- GLSLstd450InterpolateAtOffset

These functions essentially replicate the behavior of
regular interpolants in the fragment shader processing.

A specific extra difficulty encountered here is detecting
which kind of pointer offset we are dealing with. Pointer
offsets might be caused by [] operators being used on a
vector or on an array (possibly an array of vectors). This
distinction is important as it impacts what interpolant
offsets point to. Note that there's missing coverage in
dEQP-VK for interpolant arrays and this was caught with
SwANGLE tests (a dEQP-VK issue will be logged shortly).

Another issue was dealing with dynamic interpolant offsets,
which was solved by looping over all of them and combining
all plane equations into one before performing the
interpolation.

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