Previously, vertices would be processed in consecutive groups of four
(for SSE/NEON). Now four indices are read from the index buffer.
Reading the input was already a gather operation, but with constant
stride. The vertex cache now performs a scatter. The vertices are
written in reverse order so that the first vertex in a group is always
present in the cache.

Also use 2^32-1 as invalid vertex cache index (corresponds with the
primitive restart index) instead of 0x80000000, since
maxDrawIndexedIndexValue is UINT32_MAX.

Bug: b/27351835
Test: dEQP-VK.glsl.loops.special.do_while_dynamic_iterations.dowhile_trap_vertex
Change-Id: Ic69dbf53c67cbda50e44913ccae91aaca2b86e21
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32609
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Also reorder fields to reduce space wasted on alignment padding, and
shuffle writing them to the vertex cache in the same order for
consistency.

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

The blitter was not doing the sRGB conversion on the first of
N source samples when accumulating samples for doing an sRGB
resolve.

This cl also includes Chris' initial fix for PixelRoutine and
SpirvShader. See:
https://swiftshader-review.googlesource.com/c/SwiftShader/+/31928

Change-Id: I97ce06fb39788fd623eb9b5c0203e45fd911c1dd
Tests: dEQP-VK.renderpass.suballocation.multisample.*.samples_4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32848Tested-by: Alexis Hétu <sugoi@google.com>
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

- It is acceptable to pass a larger array to these functions than you
  actually need. The functions are specified to overwrite the `count`
  parameter with the number of elements actually written. Previously we
  would assert in debug, or in release we would leave the input count
  unmodified, which would lead an app which uses this pattern to
  consider uninitialized junk to be valid elements.

- It is acceptable to provide a pointer to a result buffer *and* a
  count of zero. This should return VK_INCOMPLETE if there are any
  elements. We mishandled this in physical device and physical device
  group queries.

Bug: b/117974925
Test: dEQP-VK.api.info.*
Change-Id: I2764831726bb4911ba4cab847fa4b404817508c5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32749Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Currently we don't restrict any of the parameters (x, y, width, height)
to glScissor aside from forcing width and height to be non-negative.
This means large parameters can cause overflows during the scissor test.

So we change width/height in the cases where an overflow will happen.

Bug chromium:969071

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

The output registers and memory clobber were not being properly
specified, which can cause incorrect compiler transformations when these
functions are inlined cross-module via ThinLTO.

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

The code was using the LSB instead of the MSB.
Added shifts to fix the issue.

Change-Id: I6bdfc367c6daea98b0dd8878ea9c0076574206f5
Tests: dEQP-VK.renderpass.suballocation.multisample.a2b10g10r10_unorm_pack32.samples_4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32789
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Needed to fix this build error with ToT gn:
https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8911014495686240880/+/steps/analyze/0/stdout

Gn does not know how to add a "*.lds" file in sources, and adding
"libvk_swiftshader.lds" to sources does not have any effect on the generated
ninja files.  With ToT gn, this becomes an error.  This CL changes the file to
be added to inputs, which will cause the target to get relinked when the file
changes.

BUG=chromium:964411
R=capn

Change-Id: Ib931f3ec886f06ad53cdc3b89d78e973e6b0aae3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32628Tested-by: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

The spec states that "Applications must not pass any other values than
VK_TRUE or VK_FALSE into a Vulkan implementation where a VkBool32 is
expected." So we should avoid the use of C++ true/false and literal 0/1
when dealing with VkBool32 values.

Note that we test for 'condition != VK_FALSE' to evaluate whether the
condition should be interpreted as true. This is both more efficient
than testing for 'condition == VK_TRUE' and follows the principle of
least surprise in the event an application does provide another value.

Bug: b/134584057
Change-Id: I219172a2c538b0f0cb3f173ffd905adb8814b932
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32408
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

Prior to this change, the OpenGL compiler accepted all "non-struct"
"non-array" types for unary operations (++, --, and -). This ignored
the existence of sampler objects. If someone tried to negate a
sampler, then the compiler would tell the assembler to negate a non-
numerical type.

This change makes it so the GSL compiler only accepts unary operations
on numerical types (including vectors and matrices).

Also added a unittest that makes sure we gracefully fail to compile
bad unary operations.

Bug chromium:910883

Change-Id: Ia69056b31664900c3126cab42ecb8603d1a5d7db
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32448Tested-by: Sean Risser <srisser@google.com>
Presubmit-Ready: Sean Risser <srisser@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Previous change missed removing this line somehow...

Change-Id: I049142c6e5387414eb2c16aebaeaef1387f27734
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32709
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Vmos are now non-resizable by default, so the non-resizable flag is no
longer necessary and will be removed.

Change-Id: I6752d414e59d651dbd4d95f815d6ecbac3e6eb6b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32708Reviewed-by: Wez <wez@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: David Stevens <stevensd@google.com>

CL:32489 caused a compilation error on Android since it
implicitly deletes BackingMemory's default constructor.

Change-Id: I48d415aed8ad0166d8d2bd61d06d9ad5ba8a565c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32629
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Hernan Liatis <hliatis@google.com>

SwiftConfig is unused in Vulkan, so it was removed.

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

Both windows and linux do this already using .def files and linker scripts, respectfully.
Mac's linker has the exported_symbols_list flag that acts similarly.

This is required as the SPIRV-Tools in dEQP now collides with the version in SwiftShader, leading to horribly cryptic crashes deep in SPIRV structures.

Change-Id: I3641744ae2439bf05468b6f10cf3da0307614534
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32568
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

This dependency was not explicitly declared, and just so happened to be implicitly pulled in on x64. It isn't pulled in on arm though.

Upstream fix: https://reviews.llvm.org/D63144

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

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

Change-Id: I462565f2b0397795d953898c24fa55c48b04dcab
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32650Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

All switch control flows return, but the compiler doesn't seem smart enough to notice this.

This magically started happening when I switched to using ninja, possibly suggesting that it is either suddenly using a different compiler or the flags are different.

While something I'll try investigating, here's a fix all the same.

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

Change-Id: I89cbaf2fa693f4fb3685537fd82ca7fce5773ea4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32648
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

There's now only a handful of tests that are not passing and are not UNSUPPORTED. We might as well test these too.

Change-Id: I3bbc4d7db0c7adbf9225eff9f968b543013e8447
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32570Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

data is the 0th argument to the coroutine.
There's no good reason why this was stored as a field when all other arguments were fetched in ComputeProgram::emit().

Having this as a field caused a data race in the rr::Variable materializing, as the destructor of this field was called outside the reactor mutex.

Test: dEQP-VK.synchronization.internally_synchronized_objects.pipeline_cache_compute
Bug: b/133127573
Change-Id: I44545b71714fdebd8f1150bf7d6325f7d4d4d3eb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32569
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

vkgetSwapchainGrallocUsageANDROID() now sets
a single flag to GRALLOC_USAGE_SW_WRITE_OFTEN

Bug: b/122837237
Change-Id: I809659c6bbc49b84302b8c58751de5ed0135b1ef
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32249Tested-by: Hernan Liatis <hliatis@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

Add support for function as dictated by the Vulkan spec
for Xlib WSI (32.4.5)

Bug: b/124265819
Change-Id: I61e9ca4b34c7b57102d32ff24cecde2b9e513a5f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32228
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Hernan Liatis <hliatis@google.com>

- Take the pipeline's multisample mask into account when generating
cMask
- Wire up cMask to the BuiltInSampleMask input

Bug: b/118386749
Test: dEQP-VK.pipeline.multisample_shader_builtin.sample_mask.pattern.*
Change-Id: Ia65ba31c6a73f87f537164c69e2d3086b82ea27e
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32528Tested-by: Chris Forbes <chrisforbes@google.com>
Presubmit-Ready: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Cleaned up items include:
- Sanitized parameter names in Command constructors
- Commands no longer hold Vk types for members if they
  can be cast to an internal type in the constructor
- Commands members are private
- VertexInputBinding contains a Buffer instead of a VkBuffer
- Removed the Fence default constructor
- Image functions now receive Image and Buffer objects
  instead of VkImage and VkBuffer handles.
- Removed the VkNonDispatchableHandle default constructor
- DeviceMemory::getOffsetPointer() is now const
- Refactored PresentImage so that it no longer contains
  VkImage and VkDeviceMemory handles, but proper Image
  and DeviceMemory objects instead and replaced duplicate
  code which releases these objects with a clear() function.
- SwapchainKHR no longer holds on to a VkSwapchainCreateInfoKHR
  structure, which was dangerous, since it contains pointers
  which were not deep copied, but only holds on to a SurfaceKHR
  object, which is the only thing it really needs.
- SwapchainKHR::images never changes size, so it was changed
  from a vector to an array so that we can better control its
  memory allocation.
- SurfaceKHR had a VkSwapchainKHR member, changed it for a
  SwapchainKHR* instead
- Removed surfaceFormats and presentModes, which were
  unnecessarily bloating the SurfaceKHR class and moved
  them to an unnamed namespace in VkSurfaceKHR.cpp.

Change-Id: If21e5ba1319759a204e562aef92aaf96d5a12b1f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32489
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Sean Risser <srisser@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Change-Id: If17698c9dd9aeb3d730057cf6462f9e7703c9383
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32548Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

vk-master.txt is android/cts/master/vk-master.txt | grep -v wsi
vk-master-risky.txt is android/cts/master/vk-master-risky.txt | grep -v wsi
vk-wsi.txt is external/vulkancts/mustpass/1.1.3/vk-default.txt | grep wsi

Note that the WSI list comes from the other side -- Android's mustpass
excludes the WSI tests for other platforms, which we want to run.

Change-Id: I53c2d010ebb5b862dd3f90e94ec07834b5d8651f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32588
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Much quicker at incremental builds.
Also print when the build has finished.

Change-Id: I3bd74ddb501b4a2584fc2cbd9bd85b250ce117be
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/31834Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

- Added separate mutexes for both caches in the Blitter and used
  std::mutex instead of MutexLock.
- Removed some now unused inclusions/forward declaration from the
  Context class and fixed the fallout of doing that in other files.
- Also moved SwiftConfig to std::thread/std::mutex
- Removed unused inclusions of System/Thread.hpp where possible.

Bug b/132280877

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

sw::Resource is only used by the Renderer class and the
functionality used is simply one of a WaitGroup. The sync
variables has been changed from a Resource to a WaitGroup
and the Resource class has been removed.

Bug b/133127573

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

Change-Id: I459419261b9b236dbdd617a92abb61fe5ce3ced1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32508
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Change-Id: I7801bcbaab10863011b3fb5016fc0e00b66ee11d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32468
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Currently our SamplerCore code performs sampling for four SIMD lanes
simultaneously. With implicit LOD calculation for fragment shaders, all
four pixels in a quad share the same LOD and thus sample from the same
mipmap level. But for the vertex shader the LOD is always explicitly
provided, and can vary significantly between completely unrelated
vertices. Previously we only used the LOD of the first one in each group
of four.

As a workaround, process explicit-lod sampling instructions in a
lane-by-lane manner.

Bug: b/133868964
Tests: dEQP-VK.glsl.texture_functions.*
Change-Id: If4e0d3c04d29529300111d73801124080cb4b544
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32488
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

MCWasmObjectTargetWriter and TargetIntrinsicInfo never appear in the
file. ARMTargetStreamer is declared on all platforms so move it from
the ARM-only target to the shared target.

Bug: chromium:971333
Change-Id: I04229323af68e5b4d24a1d5ad6524c96460108eb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32428Tested-by: Saman Sami <samans@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

The initial issue that the workaround was fixing was that, on x86,
there are various C calling conventions (__stdcall, __fastcall,
__vectorcall) that mangle in the number of bytes used to pass the
parameters. Both Clang and the Visual Studio compiler were crashing
while attempting to calculate the number of bytes necessary so that
it can mangle the name of the function. It needs the mangled name
to emit deviceFunctionPointers, which is some large table of
function pointers. The crashes happened because not all of the
parameters of the function in question are complete, i.e. some of
them are uninstantiated templates or forward declarations.

The fix is then to include template instantiation directly into
the VK_DEFINE_NON_DISPATCHABLE_HANDLE macro. Because template
instantiation of an already specialized template causes a warning
(treated as an error in Chromium), an extra layer of indirection
was added to make sure we don't hit this issue.

Bug b/129979580

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

Change-Id: I063e3590d4ea79b2d28cc1af3a213ab37b76723d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/31248Tested-by: Chris Forbes <chrisforbes@google.com>
Presubmit-Ready: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

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

There was linux specific code in Vulkan's BUILD.gn file.

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

Notes:
- INSTANTIATE_TEST_CASE_P is now deprecated, so changed it to
  INSTANTIATE_TEST_SUITE_P. This requires and update to
  third_party/googletest.
- Updated Driver's loadSwiftShader() function to include the
  non standalone path, in order to run the tests in Chromium
- Added Vulkan unit tests to swiftshader_tests
- Added a new GN file for Vulkan unit tests. Note that it
  relies on Chromium's version of SPIR-V Tools, not on
  SwiftShader's version, in order to avoid build conflicts

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