Previously this would just repeatedly overwrite the one file, which
makes it difficult to see what's happening when you compile a pipeline
that needs 3 routines.

Change-Id: Ibab115f5ccbb17333d504e4e7948be54ca304f9d
Bug: b/123193054
Reviewed-on: https://swiftshader-review.googlesource.com/c/23469Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Routine names were passed as wide strings for the integration with
CodeAnalyst, which no longer exists.

- Rip out the remnants of the CodeAnalyst support
- Change Reactor interface to take routine names as const char *

Bug: b/123193048
Change-Id: I919ce3a55c59c3a08057f85cac994fbffad37614
Reviewed-on: https://swiftshader-review.googlesource.com/c/23908Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

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

The error that appears when trying to build swiftshader master as part
of android is:
external/swiftshader/src/Shader/Shader.cpp:1886:51: error: expected '(' for function-style cast or type construction

Change-Id: I667f249e46ed99c3c598490182e495c0862c64a9
Reviewed-on: https://swiftshader-review.googlesource.com/c/23768Tested-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

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

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

std::make_unique is C++14, so for strict C++11, we have
to use std::unique_ptr. Added a new utility function,
CommandBuffer::addCommand, to make this change more
readable.

Change-Id: Icc62874a107543fa2c0599a338dbc6676047ad77
Reviewed-on: https://swiftshader-review.googlesource.com/c/23548Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

We always know from the context whether a particular id refers to a type
or something else. Split types out into their own map, and add an
accessor which ensures the type actually exists. This isn't so much
about checking for the provided code being valid, and more about
catching likely foul-ups in our own code.

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

Problem of supporting builtin blocks boils down to how you refer to them
from the API side -- if the reference is ONLY a SPIRV id, then block
members are difficult to work with. Instead, represent a builtin
variable binding as (id, first component, num components). For a single
variable, first component == 0 always.

Bug: b/120799499
Change-Id: If9e99f4c10f73a008e2f5071a95785920c7fbed1
Reviewed-on: https://swiftshader-review.googlesource.com/c/23488Tested-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Only missing piece here was the array size, which is available since
we support integer constants now.

Bug: b/120799499
Change-Id: I8c42aa2ced86e8358be1ffbfaa14ca87b58cc138
Reviewed-on: https://swiftshader-review.googlesource.com/c/23449Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

This is just enough support to be able to handle array sizes, etc.

Bug: b/120799499

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

Added the ClearDepthStencilImage command and made some minor adjustments
to Image clear functions to make the depth and stencil clears work.

Passes all test in:
api.image_clearing.dedicated_allocation.clear_depth_stencil_image.*

Bug b/119620767

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

Added the command to send the clear color image command
to the Image object.

Bug b/118619338

Change-Id: Ic4e00fbd49e8e043df1d2e707e3c26dadf159790
Reviewed-on: https://swiftshader-review.googlesource.com/c/23653Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>

Support for allocating, copying and clearing separate array
layers and/or mip levels in VkImage objects. As part of that,
most functions that compute memory offsets or sizes now all
take mip levels and array layers into account.

Also, since this can cause many consecutive calls to the
blitter, the blitter object is now a VkImage member rather
than being create in each function, in order to better use
the blitter cache.

Bug b/119620767

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

Allow an image of type VK_IMAGE_VIEW_TYPE_(?)D with multiple array
layers to count as VK_IMAGE_VIEW_TYPE_(X)D_ARRAY in ImageView.

Bug b/119620767

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

I'm still on the fence about leaving complex input/output definitions
intact. However, this provides enough support to walk such structures
all the way down to the leaves and determine exactly which components
are in use, what their types are, and what the interpolation qualifiers
etc should be.

Bug: b/120799499

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

Chromium enabled warning -Wmicrosoft-include which complains the line "#include "Windows/WindowsSupport.h""
in lib/Support/Windows/Threading.inc because both files are under the same folder (see below error message). The fix was
merged to Clang master at https://reviews.llvm.org/rL350655. Port the change to unblock Windows ARM64 build before
a new rolling of LLVM to swiftshader.

error: #include resolved using non-portable Microsoft search rules as:
../../third_party/swiftshader/third_party/llvm-7.0/llvm/lib/Support/Windows/WindowsSupport.h [-Werror,-Wmicrosoft-include]

Bug: chromium:893460
Change-Id: I9eb32fd92e4d96f7d22a07a7c2da70b98eba19d3
Reviewed-on: https://swiftshader-review.googlesource.com/c/23669Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Tom Tan <Tom.Tan@microsoft.com>

This works in a single pass, and supports both toplevel and member
decorations. Includes support for 5 new opcodes:

- OpDecorate introduces a single decoration for a toplevel id.

- OpMemberDecorate introduces a single decoration for a <id,
  memberIndex> pair.

- OpDecorationGroup introduces a new value category which has no
  representation downstream at all. This is safely implemented by
  doing nothing at all [we don't need to be able to introspect later].

- OpGroupDecorate applies all decorations in a decoration group to each
  of a list of other ids.

- OpGroupMemberDecorate applies all decorations in a decoration group to
  each of a list of members (<id>, memberIndex pairs).

Bug: b/120799499

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

A lot of arrays in VertexProgram and PixelProgram have fixed sizes,
so programs that have more nested loops or ifs or deeper call stacks
can cause OOB accesses, which causes security issues in Chromium.

Index clamping was added to prevent any OOB memory accesses here.

This could eventually be fixed properly by first verifying these sizes
and giving shader compile errors when these limits are exceeded.

Bug chromium:915197 chromium:915206 chromium:915218 b/116373662

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

Initial structures to bridge the shader's use of particular builtins to
behavior of the "fixed function" logic wrapped around it.

Bug: b/120799499

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

We're about to remove VertexShader, but we still care about types of
vertex attributes.

Bug: b/120799499

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

SPIRV objects have arbitrary sizes -- they are not tied to previous
shader APIs' vec4-centric view of the world. In order to be able to
allocate space for both variables and ssavalues, we need to know how
many scalar components are present in each object.

Bug: b/120799499

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

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

Half.hpp now requires <cmath>

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

Many other pieces will need an index of spirv-id to defining
instruction. Start building that up.

Bug: b/120799499

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

This will eventually replace Shader and related subclasses. The
interesting bit here is the instruction iterator, which allows fairly
safe access to the instruction stream without needing the rest of the
code to care too much about the physical layout.

Bug: b/120799499

Change-Id: Id0d94c4b807ddb1e4325de147ca1f651171779b7
Reviewed-on: https://swiftshader-review.googlesource.com/c/23049Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

vkGetPhysicalDeviceImageFormatProperties is required to return
VK_ERROR_FORMAT_NOT_SUPPORTED when the format is not supported.

CTS (validly) assumes that the format /is/ supported if this function
returns VK_SUCCESS.

Bug: b/119620767
Change-Id: I1f7d3ff8dbbfbc2dd100af7c3c4d7204f350dd06
Reviewed-on: https://swiftshader-review.googlesource.com/c/23668Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Shamelessly copied the FP32 -> B10G11R11 and FP32 -> E5B9G9R9
conversion functions from Angle. This allows packing the clear
color for these formats into a single 32 bit integer, which can
then be used within the fast clear function.

Tested using:
api.image_clearing.core.clear_color_image.*.b10g11r11_ufloat_pack32
api.image_clearing.core.clear_color_image.*.e5b9g9r9_ufloat_pack32

Bug b/119620767

Change-Id: Ic268da62959582f084245e88181374213734760f
Reviewed-on: https://swiftshader-review.googlesource.com/c/23650Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>

Added the missing 5_6_5, 2_10_10_10, 4, 8, 16 and 32 bit formats
that have integer based internal representation. Most of these
are the same as existing formats or trivial modification of
existing formats.

This only adds the ability to WRITE to these formats for now, as
these codepaths were tested using:
dEQP-VK.api.image_clearing.core.clear_color_image

If reading these formats becomes exercised by other tests, they
will be added at that point.

Bug b/119620767

Change-Id: I85317d7cfab6b1e708d6e6500ff44b83065a1d16
Reviewed-on: https://swiftshader-review.googlesource.com/c/23649Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>

A few warnings were causing build errors on Arm 64.
Since we don't want to modify the LLVM code itself,
the warnings in the LLVM code are now suppressed.

Bug chromium:922089

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

Change-Id: Idb38063e6d8f7c6345118b2acddba4dcb99d0831
Reviewed-on: https://swiftshader-review.googlesource.com/c/23588Tested-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

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

Added fuchsia-specific versions of allocateExecutable() and
markExecutable().

Bug: chromium: 778467
Change-Id: I027f1409f7b0343e102f98fcc34f2e93c2d626e4
Reviewed-on: https://swiftshader-review.googlesource.com/c/23408Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Sergey Ulanov <sergeyu@chromium.org>

llvm::parseIR in llvm-7.0\llvm\lib\IRReader\IRReader.cpp calls parseAssembly
which is defined in lib/AsmParser/Parser.cpp, but the latter file is not
included in swiftshader_llvm which causes unresovled symbol for linking.
This CL added the necessary source files under llvm\AsmParser to
swiftshader_llvm.

This CL also changed __rdtsc() to use Windows ARM64 intrinsic _ReadStatusReg
to get cycle counter as alternative of __rdtsc().

Bug: chromium:893460
Change-Id: I269662f2e4249a3ec5495ecad02bc759139e1d4f
Reviewed-on: https://swiftshader-review.googlesource.com/c/23508Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Tom Tan <Tom.Tan@microsoft.com>

The .def file is already in sources, which means GN will already add
this flag automatically (cf `gn help sources`).

No intended behavior change.

Bug: none
Change-Id: Ic8204bbdd9da47f3731d48e62ccfeb880ac9eddc
Reviewed-on: https://swiftshader-review.googlesource.com/c/23528Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nico Weber <thakis@chromium.org>

Change-Id: I37dfecd8c92f3f34c117432956d169f4b191c849
Reviewed-on: https://swiftshader-review.googlesource.com/c/23248Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Milko Leporis <milko.leporis@mips.com>

Blitting from a higher bit depth source to a lower bit depth
destination was not working properly because Vulkan expects
clamping, while the blitter was truncating the values.

From section 19.5. Image Copies with Scaling:
"Signed and unsigned integers are converted by first
 clamping to the representable range of the destination
 format, then casting the value."

This fixes all remaining failures in:
dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.color.*

Bug b/119620767

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

Added support for reading the following formats in the Blitter:
- VK_FORMAT_B10G11R11_UFLOAT_PACK32
- VK_FORMAT_E5B9G9R9_UFLOAT_PACK32

Fixes all failures in:
[dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.color]
.b10g11r11_ufloat_pack32.*
.e5b9g9r9_ufloat_pack32.*

Bug b/119620767

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

Implemented Float <-> Half conversion. The conversion is copied from
Half.cpp and is the same as the C++ code, converted to Reactor code.
The conversion is NOT optimized. Optimizing this code path will be
done later, this cl only cares about correctness.

Passes all conversion tests to and from half float in the following
patterns:

[dEQP-VK.api.copy_and_blit.core.blit_image]
.all_formats.color.[supported format].r16_sfloat.*
.all_formats.color.[supported format].r16g16_sfloat.*
.all_formats.color.[supported format].r16g16b16a16_sfloat.*
.all_formats.color.r16_sfloat.*
.all_formats.color.r16g16_sfloat.*
.all_formats.color.r16g16b16a16_sfloat.*

Bug b/119620767

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

Added support for VK_FORMAT_A1R5G5B5_UNORM_PACK16 in the Blitter.

Passes all tests in:
[dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.color]
.b4g4r4a4_unorm_pack16.a1r5g5b5_unorm_pack16.*
.r8g8_snorm.a1r5g5b5_unorm_pack16.*
.a8b8g8r8_unorm_pack32.a1r5g5b5_unorm_pack16.*
.a8b8g8r8_snorm_pack32.a1r5g5b5_unorm_pack16.*

Bug b/119620767

Change-Id: I366cb5697b60b4f0fb51931a6be7b8732cf789ec
Reviewed-on: https://swiftshader-review.googlesource.com/c/23328Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>