Also always clear the UUIDs first so that shorter strings don't leave
data undefined.

Bug b/116336664

Change-Id: I77d5ae1514db5d68d540614b7c57c4872695ecca
Reviewed-on: https://swiftshader-review.googlesource.com/c/22490Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

This enables running the unit tests without manually querying each entry
function. The compiler generates a .lib file for us which load the .dll
file and retrieves the entry functions.

Also fix project dependencies and DLL path.

Bug b/116336664

Change-Id: I4cbd80bd071a20058b034db8fb12e31f9af2e081
Reviewed-on: https://swiftshader-review.googlesource.com/c/22489Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

The popup dialog for waiting for the debugger was missing a resource,
causing DllMain to fail and thus failure to load the DLL.

Bug b/116336664

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

Changed limits for lineWidth and pointSize so that they're unsupported.
This fixes all remaining failures in dEQP-VK.api.info.device

b/117974925

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

For some reason, the Vulkan Loader prevents any dialog window from
popping up, which means that loading the SwiftShader Vulkan DLL in
Debug was always failing, unless a debugger was already attached
(as is the case when running from within Visual Studio). The
debugger wait dialog can still be easily enabled locally by setting
the DEBUGGER_WAIT_DIALOG environment variable.

Bug b/116336664

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

This fixes Chromium (mips64el) cross-comile failure
for v8 snapshot for host.

Bug: b/115344057, b/117854176
Change-Id: I0a348701151b9db288a3de84ef22c23bbd007a80
Reviewed-on: https://swiftshader-review.googlesource.com/c/22408Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Milko Leporis <milko.leporis@mips.com>

A hang in Chromium on MacOS seems related to attempting to load
libGLES_CM repeatedly, since it doesn't exist. While dlopen()
probably shouldn't be this slow, it could also be related to a
sandboxing issue. In any case, this cl attempts to go around the
issue by never trying to load a library twice.

Bug chromium:904346

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

Some classes were given the following attribute:
[[clang::lto_visibility_public]]

This produces a warning in Visual Studio.

This was meant to allow these base classes to be visible
to both libEGL and libGLESv2. Vulkan will be a single DLL,
so this won't be an issue, so I simply removed both
instances of this attribute in the Vulkan project.

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

4 basic things here:
- Set SwiftShader formats to match the equivalent Vulkan format,
  when available
- Removed SwiftShader formats with no exact match in Vulkan formats
- Added all currently unavailable Vulkan formats in comments in the
  list, possibly to be added later, when necessary
- Marked all mandatory sampled formats in the list (in comments)

Bug b/118429780

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

-W[error=]unused-lambda-capture is not recognized by GCC.

Change-Id: I6d1bfc470c4afc0e72b76d2a26efb85eb8d8c8fb
Reviewed-on: https://swiftshader-review.googlesource.com/c/22368Reviewed-by: Takuto Ikuta <tikuta@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Takuto Ikuta <tikuta@google.com>

Deterministic loops use the first scalar of the SIMD register used as
the loop index, for addressing arrays. This means that operations on the
index register should not be masked (i.e. it should be treated as a
scalar).

Previously we were still masking it based on conditional statements, and
we didn't disable the masking altogether for the loop initialization and
initial test. A new shader assembly instruction 'SCALAR' was added for
doing this.

Previously this was conflated with the 'TEST' instruction, which should
independently disable/restore the 'continue' mask.

Bug swiftshader:93
Bug b/118009174

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

Vulkan doesn't require any fixed-function vertex and pixel processing.

Bug b/117152542

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

Bug b/117152542

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

This is re-land of
https://swiftshader-review.googlesource.com/c/SwiftShader/+/21848

bug: chromium:681136
Change-Id: I11ca3b0f3ccd00ff93cf5eec0e342b49d2ce1f99
Reviewed-on: https://swiftshader-review.googlesource.com/c/22289Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Takuto Ikuta <tikuta@google.com>

* LLVM reactor backend: requires LLVM 7.0
* Subzero reactor backend: not supported

Bug: b/117854176
Change-Id: I7b76ebf854f65c2d111552552bd5a81c049d3b50
Reviewed-on: https://swiftshader-review.googlesource.com/c/22308Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Gordana Cmiljanovic <gordana.cmiljanovic@mips.com>

This reverts commit d0d9928f.

Reason for revert: This broke build, NumElements needs to be captured in debug build

Change-Id: If5d8579a48229af9ff5a75dc7baeb544b195b746
Reviewed-on: https://swiftshader-review.googlesource.com/c/22288Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Takuto Ikuta <tikuta@google.com>

We can use const local variables without capturing.

bug: chromium:681136
Change-Id: I2df60e02920841222b6e63aaa2be3ecbb8d6db2c
Reviewed-on: https://swiftshader-review.googlesource.com/c/21848Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Takuto Ikuta <tikuta@google.com>

Reactor is a run-time code generator so it only needs to support the
CPU architecture for which it is being compiled. This reduces (static)
compile time and potentially the binary size.

Bug b/115344057

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

The test expression of a loop is placed between the TEST and ENDWHILE
shader assembly instructions, and should no longer be affected by the
cleared execution mask of a continue statement. Thus TEST should always
be emitted, even for non-deterministic loops.

Other masks should still apply, and work recursively, so the
'whileTest' boolean to disable all masks during the test expression
evaluation has been replaced with a stack to restore the continue mask
at the TEST instruction.

Bug swiftshader:93
Bug b/118009174

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

These were moved to the Chromium repo in
https://chromium-review.googlesource.com/1311084

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

Change-Id: I8f4dc30c4bace3c2a95c72b3fdd8b4eb200c80cd
Reviewed-on: https://swiftshader-review.googlesource.com/c/22249Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

It's not available on older versions of macOS.

Bug b/115344057

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

The Mach-O executable format, used on macOS/Darwin, stores function
names in mangled form, so we need to mangle it ourselves during
function pointer lookup.

Bug b/115344057

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

Reactor is a run-time code generator so it only needs to support the
CPU architecture for which it is being compiled. This reduces (static)
compile time and potentially the binary size.

Bug b/115344057

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

Bug b/115344057

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

This enables LLVM reactor backend to be used for mipsel
in Chromium, though Subzero remains the default option.

Bug: b/117854176
Change-Id: I8c66017cd3a966202b61f8cbd65e065e3512e1e5
Reviewed-on: https://swiftshader-review.googlesource.com/c/22008Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Gordana Cmiljanovic <gordana.cmiljanovic@mips.com>

Initialization order mismatch is treated as an error with Clang/GCC:
-Werror=reorder

Bug b/118383648

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

Calling ClearBuffer* on an incomplete framebuffer was crashing
because a depth clear assumes 4 bytes per pixel and the type of
an incomplete framebuffer could be anything, which is potentially
smaller than 4 bytes, so memory was written out of bounds.

ClearBuffer* now also checks for completeness, just like clear
already does.

From the OpenGL ES 3.0 spec, section 4.4.4.4
"Effects of Framebuffer Completeness on Framebuffer Operations

 Attempting to render to or read from a framebuffer which is not
 framebuffer complete will generate an INVALID_FRAMEBUFFER_OPERATION
 error. This means that rendering commands (see section 2.6) ...
 will generate the error INVALID_FRAMEBUFFER_OPERATION if called
 while the framebuffer is not framebuffer complete"

And from the OpenGL ES 3.0 spec, section 2.6 Rendering Commands
"GL commands performing rendering into a framebuffer are called
 rendering commands, and include the drawing commands Draw* ...,
 as well as these additional commands:
• BlitFramebuffer
• Clear
• ClearBuffer*"

Bug b/117048995

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

Previously -Wno-header-hygiene was added to cflags only on x64, so the
compiler was generating a lot of warnings when compiling for arm64.
Now this flag is added on all platforms.

Also removed -Wno-null-dereference - it doesn't generate any warnings.

Change-Id: Id145404dba169da64a6febdec2732aec681a11bd
Reviewed-on: https://swiftshader-review.googlesource.com/c/22028Tested-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Bug b/115344057

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

Assigning string literals to char* has been deprecated since C++98 and
is now an error in Visual Studio. Also, a goto which skips variable
nationalizations is an error now.

std::min/max are defined in <algorithm>

Bug swiftshader:121

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

This cl adds Buffer, BufferView and DeviceMemory.
- DeviceMemory contains the appropriate logic to allocate and map
  device memory.
- Buffer simply wraps a DeviceMemory and an offset for now.
- BufferView wraps a Buffer with a memory region and a Format.

Bug b/118383648

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

Also fall back to LLVM 3.0 automatically if C++11 is not supported.

Bug b/115344057
Bug b/116540140

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

Bug swiftshader:121

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

- Version exposed with each extension is the revision of the extension
  itself, not the API version.

- Instance and device extensions must be exposed in the correct lists

- Handle VK_INCOMPLETE case

V2: Also handle excessive count

Bug: b/116336664
Change-Id: I97ad644359b761142f397855e49c0651181b3e77
Reviewed-on: https://swiftshader-review.googlesource.com/c/21968Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Bug: b/117854176
Change-Id: I3732949af676a313e6ad284efcb91a90acd651ff
Reviewed-on: https://swiftshader-review.googlesource.com/c/21868Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Gordana Cmiljanovic <gordana.cmiljanovic@mips.com>

The OpenGL ES 3.0 spec states:
An INVALID_OPERATION error is generated if attachment is COLOR_-
ATTACHMENTm where m is greater than or equal to the value of MAX_COLOR_-
ATTACHMENTS.
An INVALID_ENUM error is generated if attachment is not one of the attachments
in table 4.6, and attachment is not COLOR_ATTACHMENTm where
m is greater than or equal to the value of MAX_COLOR_ATTACHMENTS.

Bug b/116776063

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

There are no plans to fix them, so let's suppress it.

Bug: b/118397735
Change-Id: Ie2b621e1cf315a8e24c9b29b6e2bf8a7762e7b6e
Reviewed-on: https://swiftshader-review.googlesource.com/c/21889Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Aurimas Liutikas <aurimas@google.com>

Bug swiftshader:64

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

Deterministic loops use the first scalar of the SIMD register used as
the loop index, for addressing arrays. This means that operations on the
index register should not be masked (i.e. it should be treated as a
scalar).

Previously we were still masking it based on conditional statements, and
we didn't disable the masking altogether (using the 'TEST' instruction)
for the loop initialization and initial test.

Also, non-deterministic loops should not have any execution masking
disabled, so don't emit 'TEST' for them.

Bug swiftshader:93
Bug b/118009174

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