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>

* LLVM reactor backend: requires LLVM 7.0
* Subzero reactor backend: unittests hit unimplemented
  TargetMIPS32::lowerShuffleVector()

Bug: b/117854176
Change-Id: Ie58e3e438db6f1b442b05efecf9b645aff82321a
Reviewed-on: https://swiftshader-review.googlesource.com/c/21748Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Milko Leporis <milko.leporis@mips.com>

Signed integer overflow is undefined behavior in C++.

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

We pass integer uniforms as floating-point ones, which can cause an
exception when converting them to fixed-point values. For example an
integer value of -1 would be 0xFFFFFFFF which is Not-a-Number in
IEEE-754 floating-point and can't be cast to an integer.

In this case we don't actually care about the result because the fixed-
point number is only used by the fixed-function pipeline. A safe but
still fast way to compare floating-point numbers including NaNs is to
treat them as one's complement integers, which can easily be converted
into two's complement representation.

Also rename bitCast<> to bit_cast<> to match the C++20 function.

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

This cl adds basic functionality to Device and PhysicalDevice
features and properties. Every setting and feature is either
set to the most basic setting, or disabled, when possible.

Bug b/117974925

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

The CommandBuffer object is a large portion of the Vulkan API.
To make reviewing it's implementation easier, this cl simply adds
all the CommandBuffer function signatures and UNIMLPEMENTED functions.

Bug b/116336664

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

Vulkan has multiple synchronization objects:
- Events, which provide synchronization between commands submitted
  to the same queue, or between the host and a queue.
- Fences, which insert a dependency from a queue to the host
- Semaphores, which insert a dependency between batches submitted
  to queues

For now, SwiftShader will treat these synchronization primitives as noop, since:
- Commands will be executed in order
- SwiftShader currently only supports 1 queue

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

Added small Vulkan unit tests:
1) Checks that all API functions are present
2) Verifies a few Physical Device properties

The tests are currently only for Visual Studio,
but should be easily ported to other platforms,
as the code is similar to the GLES unit tests.

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

GLES unit tests were in the generic "unittests" directory.
In order to avoid confusion with Vulkan unit tests, the
GLES unit tests directory was renamed to GLESUnitTests.

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

On linux, clang is unable to find the Cast() function used in the
templated destroy() function unless it has already been defined
before the template function. This forces us to make sure all
Cast() functions are available, but simply adding the vulkan objects'
header files in VkMemory.h would cause a circular dependency, which,
while it would be properly guarded by the preprocessor directives,
wouldn't guarantee any include order, due to the nature of circular
dependencies. So, to fix the issue, a new header file, called
VkDestroy.h was added, which can depend on all vulkan objects' header
files without creating a circular dependency.

Also fixed some warnings.

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

Bug b/116778367

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

LLVM_DEFAULT_TARGET_TRIPLE was defined in config.h and llvm-config.h,
which was causing warnings when compiling it for Fuchsia. Also made
some other cleanups in llvm-config.h, particularly removed i386 and arm
ifdefs.

There are still some other warnings not fixed in this CL
('using namespace' in headers), but these don't look Fuchsia-specific.

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

Bug b/115344057
Bug chromium:881334

Change-Id: Id3d673b8cf9ff3d3eea0675b1b58f0f6663ba074
Reviewed-on: https://swiftshader-review.googlesource.com/c/21528Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>

The implementation of OpenGLES_v2 glCompressedTexSubImage2D() API
lacks of a sanity check for compressed formats. When a
non-compressed format is specified (e.g. GL_RGB), an unreachable
condition of SS's internal function, ComputeCompressedSize(), is
hit.

This patch is to add a check in CompressedTexSubImage2D() function
to prevent invalid formatd from being entered, in terms of
OpenGL_v2 API integrity in accordance with Khorons's specification

Bug: b/116776984
Test: Manual tests using OGLESHelloAPI by specifying GL_RGB format
Change-Id: Icc964ecb9dbbdef6c6bc82dab42c35290917159e
Reviewed-on: https://swiftshader-review.googlesource.com/c/21548Reviewed-by: Merck Hung <merckhung@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Merck Hung <merckhung@google.com>

Note that this is left undefined by the spec, but glGetBoolean converts
non-zero integers to GL_TRUE, so this makes things symmetric.

Bug swiftshader:90

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

Vulkan has a few dispatchable objects: Instance, Device, Physical Device,
Command Buffer and Queue. These objects, when loaded through an ICD, are
constrained to have a bit of memory allocated at the beginning of these
objects to contain loader data.

In order to do this, a wrapper class, DispatchableObject, was created to handle
pointing directly to the loader data when casting to the associated VK handle
and similarly back to a pointer to the internal object. Note that Queue, being
allocated within another object, and not directly through the API, simply have
the loader data at the beginning of the class, without requiring a wrapper class.

Also, since all these object are allocated through a custom placement new
operator, they have to be deallocated through an associated destroy() function,
so the DispatchableObject destructor is deleted, in order to prevent these
objects from being released any other way.

Bug b/116336664

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

Bug b/115344057
Bug chromium:881334

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

This enables supporting ARM64 for Chromium.

Bug b/115344057
Bug chromium:881334

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

Bug b/117564133
Bug swiftshader:104

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

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

Bug b/115344057
Bug swiftshader:16

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

Bug b/115344057
Bug swiftshader:16

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

Core SwiftShader should no longer be able to allocate executable
memory. That responsibility now falls entirely on Reactor.

Bug b/115344057
Bug swiftshader:16

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

This is accomplished by duplicating files from the Common directory
that Reactor (both with LLVM and Subzero back-end) depended on. They
will be minimized in the next change.

Bug b/115344057
Bug swiftshader:16

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

This prevents clashes between intermediates. Also update the D3D8
project to not depend on debug macro implementations in the
SwiftShader layer.

Bug b/29024574

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

We were using sw, the namespace used in the rest of SwiftShader, as the
namespace for Reactor. Putting Reactor code into its own namespace
makes it easier to untangle dependencies.

Bug swiftshader:16
Bug b/115344057

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

Adds commit '65ce2e56889' from https://git.llvm.org/git/llvm as
'third_party/llvm-7.0/llvm'

Commands:
git remote add llvm https://git.llvm.org/git/llvm.git
git subtree add --prefix third_party/llvm-7.0/llvm llvm release_70 --squash

Bug b/115344057

Change-Id: I981f7e2fc47639ca8a8998b188e837bc3f268de5

git-subtree-dir: third_party/llvm-7.0/llvm
git-subtree-split: 65ce2e56889af84e8be8e311f484a4dfe4b62d7a

LLVM 7.0 will be added back as a subtree instead.

This reverts commit 1841c50c.

Bug b/115344057

Change-Id: I5fc51be1f107f3de0e97e8b53e282b0cc9557bed

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

This reverts part of https://swiftshader-review.googlesource.com/21108

Bug b/73656151

Change-Id: I35c91cb5b28ede65eadebcb5e8141be4cf3f2e0e
Reviewed-on: https://swiftshader-review.googlesource.com/c/21368Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Shannon Woods <shannonwoods@google.com>

Bug b/116336664

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

Bug b/117152542

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

The Vulkan implementation needs a directory for each architectural
layer, similar to the OpenGL ES stack. The entire rendering stack is
duplicated, leaving only Reactor common between them:

Renderer -> Device
Shader -> Pipeline
Common -> System
Main -> WSI

Bug b/117152542

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

Although we only produce libraries, 'lib' is confusing as an output
directory. We already used 'out' for the CMake build.

Bug b/116336664
Bug b/29024574

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

The Vulkan implementation shouldn't depend on any of the legacy
directories. Also, changes to the environment-wide include paths
may have undesired consequences.

Bug b/116336664

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

Bug swiftshader:116

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