Bug: b/143479561
Change-Id: I1a63f7eab9d5b6ce12f5d858018c4c6582ab9c90
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37669
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Bug: b/143479561
Change-Id: Id6039b31790eb181daf669dff43cd46f92d464d7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37748Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/143479561
Change-Id: Ie1b8dad6611d5fb1e2a6e4cc679c01ac98cf8e4d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37668
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

... by updating eglSwapBuffers() to give up the display lock before
calling surface->swap().

Bug: b/135742693
Test: built locally
Test: presubmit
Test: cts -m CtsMediaTestCases -t android.media.cts.HeifWriterTest#testInputSurface_Grid_Handler
Test: dEQP-GLES3 tests through cherry
Change-Id: I816d30e80077b40e8396bf8d6ae5bb236753e3ea
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37769Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

The next change will update the locking around eglSwapBuffers. Move
all the locking into libEGL.cpp to avoid duplicating getDisplayLock().

Bug: b/135742693
Test: built locally
Test: presubmit
Test: cts -m CtsMediaTestCases -t android.media.cts.HeifWriterTest#testInputSurface_Grid_Handler
Change-Id: I1ca863b4902d1dc4e456700ac96aecc3e61424ba
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37768
Presubmit-Ready: Jason Macnak <natsu@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Jason Macnak <natsu@google.com>

This corresponds to the VK_FUCHSIA_external_semaphore extension
which uses a Zircon event object to communicate across processes.

Bug: b/140421726
Change-Id: I47b235d4ff7d787491738422bda6fdf853803ab7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/35969
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: David Turner <digit@google.com>

A previous CL updated the Vulkan headers, and removed our
include for vulkan_fuchsia_extras.h, which contains
Fuchsia-specific declarations that are used by the platform
but not upstreamed yet to Khronos.

This CL simply restores the include.

Bug: 143197472
Change-Id: I934f185c76f54e08ff52a202198cb951ad4b6644
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37450Tested-by: David Turner <digit@google.com>
Presubmit-Ready: David Turner <digit@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Kokoro-Presubmit: David Turner <digit@google.com>

A mistake found its way into the previous "Provoking vertex fixes"
cl. This cl fixes the vkGetPhysicalDeviceFeatures2 function for the
VK_EXT_provoking_vertex extension.

Bug: angleproject:3677, angleproject:3430
Change-Id: I561361f3fd2c3f6b7ca524614b7d7af461cc12d4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37710
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

A few things were buggy in the last provoking vertex cl:
- There were 2 separate loops for rasterizationState extensions.
  Correctly combined them into a single loop.
- There was a missing break statement in vkCreateDevice
- There was a missing case in vkGetPhysicalDeviceFeatures2

Bug: angleproject:3677, angleproject:3430
Change-Id: Id4a16168933fc8c440b7339851a39e8cc4683491
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37688
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Adding an new extension, which is not present in the Vulkan headers,
in order for ANGLE to be able to specify to SwiftShader which
provoking vertex convention to use, in order to properly emulate
OpenGL ES on top of Vulkan, since OpenGL ES uses the last vertex
convention and Vulkan uses the first vertex convention.

Bug: angleproject:3677, angleproject:3430
Change-Id: If4e6539d48bc282af8ed6f2a9db6b2fc9d0dbe2d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37248
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

MacOS requires a few defines that were missing from BUILD.gn.
It also requires being linked to Cocoa/IOSurface/QuartzCore.
It also needs macros to define API availability to use CAMetalLayer.

Bug: chromium:1015454
Change-Id: I6b298cc805ce1f927d2eed8f4d0e11a271f75f24
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37628
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Changing the stencil reference shouldn't be causing a new fragment
shader to compile, since it has no effect on the generated program.

This cl removes the front and back stencil reference from the States
structure to avoid uselessly generating programs.

Improves the run times of a few dEQP.KHR_GLES3 tests with SwANGLE:

dEQP.KHR_GLES3/packed_depth_stencil_verify_read_pixels_depth24_stencil8
-> Test runs ~8X faster (from ~4s down to ~500ms)

dEQP.KHR_GLES3/packed_depth_stencil_verify_read_pixels_depth32f_stencil8
-> Test runs ~19X faster (from ~3.8s down to ~200ms)

Bug: b/143288278
Change-Id: Ic46db6822daa924599de0f0a9e9688f8bacc95ea
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37568
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Manually applied https://reviews.llvm.org/rL357714 to fix crash/assert
on loading SwiftShader when compiled with VS 2019 16.3.29324 and later,
and using clang-cl to compile. More information about this bug:
https://bugs.llvm.org/show_bug.cgi?id=41367

Bug: chromium:1015904
Change-Id: I83ad7feb15a6ca5d5eb0fc25fb6674d4678d60a5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37608
Presubmit-Ready: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

The destination offset wasn't taken into account in the
computation of the source offset, which is necessary
because we compute the source coordinates from the
destination coordinates in the generated routine.

Bug: angleproject:4037 angleproject:4013
Change-Id: Ib9961cec267653c8d33da1847486943f8a670a49
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37588
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

True integer types don't support MSAA, so the blitter never had support
for MSAA on true integer types. In Vulkan, VK_FORMAT_S8_UINT is a UINT
format, so it's considered a true integer type, but it must still support
MSAA.

Added support for MSAA on true integer types in the blitter so fix all
related tests with SwANGLE:
dEQP-GLES3.functional.depth_stencil_clear.*
dEQP-GLES3.functional.fragment_ops.*
dEQP-GLES3.functional.rasterizer_discard.*

Bug: angleproject:4044
Change-Id: I8e04f434f0f671999aaef23cf24cc6684fd0fc16
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37548
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

...to reduce file size of debug builds on Linux.

Bug: b/142862126
Change-Id: Idab23a044502cfebb57e6b912a6c1f95692c50c8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37388
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Paul Thomson <paulthomson@google.com>

This adds an ICD entrypoint for vkGetPhysicalDeviceWin32PresentationSupportKHR
to the Win32 platform.

This change will allow tools that make use of this function to work with the
swiftshader ICD. One such tool is my Vulkan Hardware Capability viewer, that
would crash on ICDs not implementing this.

Bug: b/143207519
Change-Id: I23552cf072595b97f3032416a51c0db13d3f87a9
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37509
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

We want to allow sRGB conversion always, except when blitting to/from
a buffer. This mimics how it's done in the non-VK path.

I also opportunistically made Options constructors explicit to make it
easier to locate instantiation sites, and renamed convertSRGB to
allowSRGBConversion to make it clear that setting this to true doesn't
mean SRGB conversion will necessarily happen.

Bug: angleproject:4011
Change-Id: I88c229e683d26246b21ef601e066df6eb429e0a6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37468
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Keeps the test lists and version of dEQP in sync.
Also helps reproducibility by removing another set of external environment flags.

Bug: b/140172528
Change-Id: Ib595a1c0c69ffedbfa7848ce8a31c3927bd78980
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37448
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

No longer disable wd4146, fix warnings, and disable this warning when
including LLVM headers in LLVMReactor.cpp, as it trips for specific
headers like MathExtras.h, StringExtras.h.

Fixes ANGLE roll.

Bug: angleproject:4034
Change-Id: I102f4c18ac47c2db8abddf1b4ceace7987e6df57
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37488
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Bresenham lines are required by ANGLE in order to support emulation
of OpenGL ES style lines on top of SwiftShader Vulkan.

Bug: b/139800520
Change-Id: I8b77775af836a238d309cc19b495b61d2c3a3487
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37428
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

A few functions:
- vkGetImageSparseMemoryRequirements2
- vkGetPhysicalDeviceQueueFamilyProperties2
- vkGetPhysicalDeviceSparseImageFormatProperties2

Can query properties/requirements from arrays of structures.
The arrays of structure look like:
struct Struct2{
..
Struct1 ...
...
};

We were wrongly converting them directly into arrays of Struct1
by taking the address of the Struct1 member in the first Struct2
object, which is incorrect. This change copies the logic for
vkGet* functions to vkGet*2 functions, adding a function to
directly support VkQueueFamilyProperties2.

Bug: b/142740524
Change-Id: Id1363f0ab82539d1bc1e3977c541602df8a618cb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37276
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

* Fixes crash when window is resized.
* Take destination pitch into account when updating the framebuffer, so
we no longer get skewed renders.
* Return VK_ERROR_OUT_OF_DATE_KHR when presenting if the swapchain image
dimensions do not match the window surface's.

Bug: b/139372840
Change-Id: I744adbf222a1d06bc9cc879e299b11b56f6dd7cf
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37429
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

Update Vulkan headers to ToT

Includes VK_EXT_line_rasterization

Bug: b/139800520
Change-Id: I054c32a29bc740679b4286818e2bac70701ef07c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37408
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Bug: b/142132927
Change-Id: I1221f85a6a84c8ff54d900b8acb444764f18cf40
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37274Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

In addProlog, most arguments are immediately assigned to a register, for
which we emit the proper frame pointer-based move instruction. However,
for arguments that are not immediately assigned to a register, which
happens when many arguments are passed in (e.g. 10), move lowering
happens later during emitIAS, at which point, we call
getFrameOrStackReg to get the base register. The problem is that
this function will always return the stack register on Windows x86,
because needsStackPointerAlignment() is true for this target. As such,
argument access uses the stack pointer, rather than the frame pointer,
which mismatches the offsets computed for these variables in addProlog.
To fix this, stackVarToAsmOperand makes sure to use the frame pointer
for variables that are arguments (not locals) when
needsStackPointerAlignment() is true.

Bug: b/142132927
Change-Id: Ia86680381e48b61e89310f1911e72517bd14b98f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37273Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/142132927
Change-Id: If3d63a8327ef8940dbeee7b49c1099adda7feab2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37275Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

This change addresses the following issues:
* Microsoft x64 ABI assigns registers to the first four arguments by
argument position, not by type count.
* Microsoft x64 ABI expects caller to allocate space to copy 4 register
arguments to stack, called the Shadow Store or Home Space.
* Fix bug where preserved register area size was not computed correctly
when Xmm registers were being preserved, as it was assuming all
preserved registers were 8 bytes large.

Bug: b/142132927
Change-Id: Ibc2d82ab117c062eed2e7f66109c9d6bbdc09a8b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37272Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

This helps to keep the current formatting used by the Subzero codebase.

Bug: b/142132927
Change-Id: I8cb37860cf535e5b0c059316e66c19ddbafafc90
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37271Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Tests calling an external function that, itself, calls back into a
Reactor-generated routine.

Bug: b/142132927
Change-Id: I5d89000d4c23804b211aec67d5b7a36778245eba
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37270Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/142132927
Change-Id: I2b375c48e67f026f1490e7faf3ef78df4f64693d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37269
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

For example, the following would fail to compile because Call tries to
return a result:

struct Class
{
    static void Foo()
    {
    }
};

Function<Void()> function;
{
    Call(SomeClass::Foo);
    Return();
}

Bug: b/142132927
Change-Id: I249144aabae1dcfc4cb04a174ae698445be382d2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37268
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

It seems like the sdk_version partially controls which
libc++ is used during compilation. This causes mismatches
when some targets specify a version and some targets do not.

Bug: b/138239233
Bug: b/142276229
Test: built locally
Change-Id: Idd4ede2fd3c162dd0edd850155daff70b2c05bd2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37168
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Jason Macnak <natsu@google.com>

This change implements getHostCPUFeatures function to enable this functionality on Windows on ARM64.
This was committed to llvm at https://reviews.llvm.org/D68139 .

Bug: chromium:893460
Change-Id: I7ae62f298683979a4ab1aa8099d6e91706b15c9b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37328
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

We were previously checking if we could read to the end of the last
row in a pixel buffer object without overrunning the buffer. Instead
we need to check if we could read to the last byte defined by the
parameters and state without overrunning the buffer.

Also added a unittest to ensure that we don't reject valid PBO
operations, and do reject invalid PBO operations.

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

It looks like clang-cl is clobbering a floating point register
when passing a floating point argument to a DLL, because the
first time glUniform1f() is called, the value is set to 0.0f.
All subsequent glUniform1f() calls work properly.

I changed glUniform1f() calls to glUniform1fv() calls in the
AtanCornerCases test to get the test to pass again, but this
is just masking the compiler issue.

Bug: chromium:1013375
Change-Id: I8363182f26c50cd50c07ccea65ab2eb640a7da76
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37348
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

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

https://swiftshader-review.googlesource.com/c/SwiftShader/+/35939
was submitted without being properly rebased. Unfortunately, the
merge was successful on the gerrit server, but led to a broken
Linux build for swiftshader_libvulkan. This fixes the issue.

Bug: 140419396
Change-Id: Ib3167e11ea4c4957cf28fa7b45305e98ca27c413
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37289
Kokoro-Presubmit: David Turner <digit@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: David Turner <digit@google.com>
Presubmit-Ready: David Turner <digit@google.com>

Add external semaphore support for Linux and Android
based on a process-shared pthread mutex + condition
variable stored in a shared memory region backed by
memfd_create().

This takes care of waiting for external semaphores
in a background thread when invoked from a Yarn fiber.

Test: dEQP-VK.api.external.semaphore.opaque_fd*

Bug: b/140421726
Change-Id: Ifa74c807d3e33914e5a37dd96650c312246c8e4f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/35939Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: David Turner <digit@google.com>
Kokoro-Presubmit: David Turner <digit@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

'linux' turns out to be a prebuilt macro for GCC (not Clang)
so using "namespace linux { ... }" actually does not compile.

This CL fixes the issue by removing the namespace, and using
Linux as a prefix for the corresponding class.

Bug: 140419396
Change-Id: I1e980bc66b2cf8f2e21d9f7076918e2b476ae4d4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37288
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: David Turner <digit@google.com>
Presubmit-Ready: David Turner <digit@google.com>