Made this change in code review without proper testing.
The "level" being set here was the input argument, rather than the data
member.

Bug: b/145685985
Change-Id: I8641701cc0600837f4dc612d29ffaa4cd63390b1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39269
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

CMake (without or without Visual Studio 2019) should be used instead
for the Vulkan build.

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

vk::dbg::ID is a strongly-typed identifier backed by an int.
ID is used to prevent implicit casts between idenfitifers of different T types.

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

In LLVM3, this conversion was subtly broken. We're now on LLVM7, where this should be
fixed.

Mostly a revert of
https://swiftshader-review.googlesource.com/c/SwiftShader/+/7354, but
also includes a subzero implementation

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

Conversion from floating-point to unsigned integer is not a native
instruction on some CPU architectures, so excercise the case where it
overflows signed int.

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

Allows us to configure Reactor backend optimization level via
preprocessor macro. Can be set via CMake arg.

Bug: b/145685985
Change-Id: I27a80b15846a8b43be5bff0505632213852a5dc6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39168Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

Only breaks in Om1 optimization mode because this code path is specific
to Om1. Broke after 01386d17 was merged because maxOutArgsSizeBytes()
now returns 32 bytes for the shadow store, so this is a rarely exercised
code path. Problem is that on x64, the new register being created needs
to match the size of the destination register, so 64 bits, not 32 as it
was assuming.

Fixes ReactorUnitTests Call_ArgsMixed, Call_ArgsPointer, IntrinsicTest_*
which were asstering with:
Assertion failed: !isScalarIntegerType(Dest->getType()) || (typeWidthInBytes(Dest->getType()) <= typeWidthInBytes(Source->getType())), file C:\src\SwiftShader2\third_party\subzero\src\IceInstX86Base.h, line 1308

Bug: b/145685985
Change-Id: I298edd5b4a286a242b351cc6267d70ecb37943fb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39169
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Reverted the hack fix from bb222a10, and implemented a proper fix.

The fix in TargetX86Base<TraitsType>::lowerCast
(IceTargetLoweringX86BaseImpl.h) was suggested by Jim Stichnoth. The
original problem is that we're trying movd an i32 to an i4i32, and since
the target Variable is long-lived, it may not get a register allocated
for it, and when that happens, we end up tripping the assert in
InstX86Movd::emitIAS() that expects the destination to have been
allocated a register. The solution that Jim suggested, and is
implemented here, is to create a temporary, short-lived, variable to
first movd into, which should guarantee a register target, since
short-lived Variables usually get registers. Then we 'mov' the temporary
register Variable to Dest, which *should* support moving the i4i32
register operand to an i32 memory operand.

I said *should* above, because with the above fix, we now trip another
assert in InstX86Mov::emitIAS (Mov, not Movd). The reason being that it
doesn't actually support moving an i4i32 reg -> i32 memory operand. I
added support for this as well (IceInstX86BaseImpl.h). Note that this
assert only tripped when building with Om1 optimization level, since O2
ostensibly optimized out the mov call.

Bug: b/145529686
Change-Id: I3c998a3e308838123cb415fcbf9f277113ac7d28
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39068
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

`ENABLE_VULKAN_DEBUGGER` is the new option to enable building of the Vulkan debugger, which defaults to off.

`cppdap` is a new library that implements the debugger protocol.

Added a stub .cpp file to try and detect any build systems that are recursively globbing into the new src/Vulkan/Debug directory.

Actual debugger implementation will come in future changes.

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

Used by the new Vulkan debugger.

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

Required by cppdap, which is used by the new Vulkan debugger.

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

Reactor's 'Int' type is specified to be 32-bit, always, and it was
implicitly assumed the C++ 'int' type has the same size. Likewise for
'short' being 16-bit.

Make this assumption explicit with static asserts.

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

This cl adds logic to propagate the 4th texture coordinate,
which is only used for cubemap arrays, and use it as the
cubemap array id.

Tests: dEQP-VK.glsl.texture_functions*cubearray*
Bug: b/144988970
Change-Id: I241b9a50a87424461647f00d442774ead8aaa0f7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38876
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: Ben Clayton <bclayton@google.com>

This reverts commit 51d98676.
No longer needed, as the root problem was fixed in
7fefd483
(https://swiftshader-review.googlesource.com/c/SwiftShader/+/37273)

Bug: b/129757459
Change-Id: I70da0bf00fd737e395a264c1f8bfd4b25325e4bc
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/37930
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

This appears to be accidentally missing.

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

These asserts were put in place to warn us if they got test coverage.
They do since https://swiftshader-review.googlesource.com/38929. All
seven are hit by the new test.

Bug: b/145836207
Change-Id: I1aba531a1d005b48185d0b3ba72b923d2997a88e
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39088
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: David Turner <digit@google.com>

The assert() can be safely removed. This was tested by doing the
following on my Linux machine.

  1) remove the assert() in third_party/swiftshader/third_party/subzero/src/IceTargetLoweringX86BaseImpl.h:6491
  2) change the 11 into 1 in src/Reactor/ReactorUnitTests.cpp:492 (to ensure full coverage of the Blend operation)
  3) cd build && cmake .. -DCMAKE_BUILD_TYPE=Debug -DREACTOR_BACKEND=Subzero && make -j32 && ./ReactorUnitTests

Without step 1), ReactorUnitTests crasehs with an assertion in debug
builds only.

Bug: None
Change-Id: I3ab3600eee0bb7a9c9a1bfc3fe091e24c4dfc366
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39053
Kokoro-Presubmit: David Turner <digit@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

Instead of calling a function with two uint32_t parameters, pass a MemoryElement structure that has named and documented fields.

This structure includes the Type field, which will be used by the debugger for knowing how to interpret the value.

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

Should fix the dEQP-VK.synchronization.basic.fence.* flakes.

Change-Id: I9995af6bdb25907b97848f1fc249f6fb8ee15e7d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39051Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

• Place all commands into an anonymous namespace. Prevents needless symbol pollution across the SwiftShader library.
• Don't use a mix of class and struct for commands - stick to using class.
• Prefix commands with 'Cmd' to avoid a symbol collision with Win32 ResetEvent.
• Remove pointless 'protected' modifiers.

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

Based on the discussions on: b/145746360#comment2

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

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

This migrates from 2-bit swizzle codes per lane to 4-bit, which reads more fluently in hex.
The order has been reversed so that the most significant nibble (leftmost on little-endian CPUs) represents the first output lane.

Fixed up Swizzle, Mask, and ShuffleLowHigh

Bug: b/145746360
Change-Id: I132bd757801a5ca543ef2b9b0ed34d0527db5bfa
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39049
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Turner <digit@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

As the name suggest, this CL adds many operations related
to arithmetic subgroup operations, i.e.:

  - Reduction / Inclusive Scan / Exclusive Scans for:

    - IntAdd, UIntAdd, FloatAdd
    - IntMul, UIntMul, FloatMul,
    - IntMin, UIntMin, FloatMin,
    - IntMax, UIntMax, FloatMax,
    - BitwiseAnd, BitwiseOr, BitwiseXor
    - LogicalAnd, LogicalOr, LogicalXor

The implementation uses a single template function to
implement all these, based on the fact that these are
all binary commutative operations.

NOTE: Only 32-bit values are supported.

To make scans efficient, a new Reactor operation, named
Blend() is introduced. It is used to mix two input vectors
using 4 3-bit indices (encoded in a single 16-bit value)
to select the result's lane values.

A new unit-test is added to ReactorUnittests to check its
behaviour. Unfortunately, the test takes about 2 minutes
on a fast workstation when doing a full scan, so it will
by default only check 1/11th of all possible values
(see comments in the patch for more details).

Also, Float4::positive_inf() and Float4::negative_inf()
methods were added, since trying to build Float4(INFINITY)
will trigger a DCHECK() in the Float4(float) constructor,
and the infinity values are required by the subgroup
floating-point scan operations.

Bug: b/142002682
Test: dEQP-VK.subgroups.arithmetic.*
Change-Id: I86f509fc47f7475ca126615ed698ee493ae835ef
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38929Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: David Turner <digit@google.com>

Only process clip/cull distances if they're actually outputted from the vertex shader.

There's still overhead of having these distances stored in each vertex / primitive, but we should optimize the structure sizes as a larger set of changes.

Bug: b/139207336
Tests: dEQP-VK.clipping.*
Change-Id: I8f04b1c3ea823bb1a8cf62f18c987e01cd0c979a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/35032Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

The clip distance is used to perform per-fragment clipping - any fragments with a negative linear-interpolated distance are discarded.

The cull distance is used to perform per-primitive culling - any primitives with all vertices with a negative distance are discarded.

Bug: b/139207336
Tests: dEQP-VK.clipping.*
Change-Id: Ia6680601b27599152f68410df47aaaa726d0b349
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/34915
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>

If you compile SwiftShader with gcc and the --coverage flag, the build
will contain coverage instrumentation. However, the coverage
instrumentation races when multiple instances of SwiftShader run in
parallel. This change makes Regres replace the string "PROC_ID" inside
the GCOV_PREFIX environment variable with an ID that is unique between
parallel dEQP processes. This allows the user to prevent races using
e.g. GCOV_PREFIX=/tmp/cov/PROC_ID

Change-Id: I227896053c5a0ea34dc8acc282014970a626785d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38928Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Paul Thomson <paulthomson@google.com>

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

The go docs say the exit code is clobbered by `-1` on abnormal exit, but
what they don't say is there's some type mangling along the way so we
see it as 255

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

This CL clarifies the macros used by the external memory and semaphore
implementations in the following way:

- Replace SWIFTSHADER_EXTERNAL_MEMORY_LINUX_MEMFD with
  SWIFTSHADER_EXTERNAL_OPAQUE_FD, and do the same for semaphore.

  This is driven by the fact that there is nothing specific to Linux
  in the VK_KHR_external_{memory,semaphore}_fd extensions. The fact
  that Linux and Android use a memfd-backed region is an implementation
  detail (that is now only captured in VkDeviceMemoryExternalLinux.h).

  This also opens the door to an OSX implementation of the extension
  that would use a Mach-based shared memory regions instead.

- Remove SWIFTSHADER_EXTERNAL_SEMAPHORE_ZIRCON_EVENT, since the
  VK_FUCHSIA_external_semaphore extension is platform-specific, and
  replace all checks against VK_USE_PLATFORM_FUCHSIA instead.

NOTE: This shall not change the generated code at all, for any
platform.

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

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

* Implement intrinsics for the Subzero backend required for
ANGLE / SwiftShader for GLES 2 and 3.
* Note that most intrinsics are implemented as "emulated". I've added
rr::emulated namespace in EmulatedReactor.hpp/cpp that contains the set
of Reactor functions that are presently being emulated. These are
invoked from SubzeroReactor until we decide to implement proper
intrinsics for these in Subzero.

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

* Implement Nucleus::createCoroutine and acquireCoroutine so that they
create a regular function for the Begin entry, and stubbed functions
for the Await and Destroy entries.
* Made Routine::getEntry const as Coroutine expects this function to
be callable from multiple threads. Subzero's implementation would
lazily finalize the entry and cache it. Now we finalize it eagerly in
acquireRoutine, and getEntry simply returns pointers.

Bug: b/130459196
Change-Id: Id9fa447ce55c7df6fb55e1c878ca021e825fecfa
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38873
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>

Subzero's sqrt intrinsic implementation was assuming only scalar float
args when moving the result to the destination, despite its sqrt
implementation supporting vector float.

Bug: b/130459196
Change-Id: I1c5baf2dc72448785add421c87900964f877ce6f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38872
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>

Under certain conditions, the Dest value of InstX86Movd doesn't get a
register allocated to it. This is unlikely the right fix, as it's
unidiomatic, but pending further investigation, this seems to do the
trick.

Bug: b/145529686
Change-Id: I5b5d5148aef04ebac957d5941779d5cd8e544098
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38871
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>

This assert happens when legalizing the operand of an InstAlloca, which
comes from when we want to allocate an IceType_v4f32 on the stack. The
ConstantInteger32 we create has the wrong type, and Subzero asserts.

Bug: b/130459196
Change-Id: I43bd5e516dcd549f5fd35a62ee97cef284a9e656
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38870
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>

This is for debugging, when ALLOW_DUMP=1.

Bug: b/130459196
Change-Id: I734d73b6996e4c3e53e38f65e47fa7f1b04bfe67
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38869Reviewed-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 includes some new rasterization tests which may be interesting for
us

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

According to the Vulkan spec:
"fullDrawIndexUint32 specifies the full 32-bit range
 of indices is supported for indexed draw calls when
 using a VkIndexType of VK_INDEX_TYPE_UINT32.
 maxDrawIndexedIndexValue is the maximum index value
 that may be used (aside from the primitive restart
 index, which is always 2^32-1 when the VkIndexType is
 VK_INDEX_TYPE_UINT32). If this feature is supported,
 maxDrawIndexedIndexValue must be 2^32-1; otherwise it
 must be no smaller than 2^24-1."

maxDrawIndexedIndexValue is already set to 2^32-1, so
there's nothing left to do but enable the feature.

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

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