We no longer build or support LLVM < 10.

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

This first implementation ignores all optional functionality, so
this is a very bare-bones implementation of VK_EXT_debug_utils.

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

Enabled depthBiasClamp in SwiftShader's PhysicalDeviceFeatures, which
will also enable any dEQP tests that rely on it.

Bug: b/160463658
Tests: dEQP-VK.dynamic_state.rs_state.depth_bias_clamp
Change-Id: Ida3ae12d30fb70a3bd7e508e276fb9a1bfc96231
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46848
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

The VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO extension structure
is safe to ignore for Linux and Fuchsia.

We already ignored it for private allocations (see vkAllocateMemory).
Some drivers can do a better job of allocating if they know that a
VkDeviceMemory will contain exactly one object with known properties.
This is the case for NVIDIA, but not SwiftShader.

For external memory, on some platforms (including Android) the shareable
object isn't just a flat blob of memory, it carries format/dimensions
etc. The AHardwareBufferExternalMemory implementation in
VkDeviceMemoryExternalAndroid.hpp obtains the image/buffer from the
VkMemoryDedicatedAllocateInfo structure to pass it to gralloc.

External memory on Linux and Fuchsia are just flat memory allocations,
so on these platforms we can ignore the dedicated allocation info.

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

Revision https://chromium.googlesource.com/external/github.com/KhronosGroup/VK-GL-CTS/+/dc4441d7695aadce377cdaa270f0027f94471a99
Branch https://chromium.googlesource.com/external/github.com/KhronosGroup/VK-GL-CTS/+log/refs/heads/vulkan-cts-1.2.3

Includes the following changes of particular interest to SwiftShader:
* VK_EXT_image_robustness tests https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/3788 https://gerrit.khronos.org/#/c/5771/
* Test multiple fragment output locations https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2179
* Test OpArrayLength with stride larger than element size https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2236
* Test negative value conversion to b10g11r11 float format https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2271
* Test exact sampling with linear filtering over a solid color https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2226
* Test filtering of YCbCr formats https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2185
* Validate samplerless descriptor writes https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2172
* Test exact sampling cases https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2170
* Add image clearing tests with multiple subresource ranges https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2169

Failures from 1.2.1 carried over:
* dEQP-VK.texture.explicit_lod.2d.sizes.31x55_linear_linear_mipmap_linear_repeat
* dEQP-VK.texture.explicit_lod.2d.sizes.31x55_linear_linear_mipmap_nearest_repeat
* dEQP-VK.texture.explicit_lod.2d.sizes.31x55_nearest_linear_mipmap_linear_repeat
* dEQP-VK.texture.explicit_lod.2d.sizes.31x55_nearest_linear_mipmap_nearest_repeat
* dEQP-VK.texture.explicit_lod.2d.sizes.57x35_linear_linear_mipmap_linear_repeat
* dEQP-VK.texture.explicit_lod.2d.sizes.57x35_linear_linear_mipmap_nearest_repeat
* dEQP-VK.texture.explicit_lod.2d.sizes.57x35_nearest_linear_mipmap_linear_repeat
* dEQP-VK.texture.explicit_lod.2d.sizes.57x35_nearest_linear_mipmap_nearest_repeat

Asserts from 1.2.1 carried over:
* dEQP-VK.graphicsfuzz.always-false-if-in-do-while
* dEQP-VK.graphicsfuzz.do-while-with-always-true-if
* dEQP-VK.graphicsfuzz.return-before-writing-wrong-color

Change-Id: I50e6a635f5fe384321115bfcbdcd7002c455650c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46608
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

For now, warn the user that we don't support building PowerVR examples
against SwiftShader on MacOS. We may eventually add support, see
b/161976310.

Bug: b/155827755
Bug: b/161976310
Change-Id: I52216664567f1c18f59dc302dd720128ed28fe7d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46988Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

The Radial Windows OS image for Kokoro comes with CMake 3.17.3, and we
only demand CMake 3.13 at the moment. The previous image had an older
version, so we had to update it before every build.

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

Before this commit, when debugging with the ReactorDebugInfo feature,
variables were being incorrectly displayed in the debugger. For
instance, given:

Int a = 1;
Int b = 2;

The debugger would not display 'a', and would display 'b' as containing
the value '1'. The reason for this was that while the Int constructor
for 'a' was executing, we invoke boost::stacktrace() to determine the
variable's source location (file and line number); however, the stack
trace would return the return address of the constructor call, which
would be on the next line -- that of 'Int b'.

To fix this, knowing that all ReactorDebugInfo emits come from function
calls in Reactor code, we assume that all backtrace addresses point to
the next instruction following the call, thus we subtract 1 from these
addresses. When resolving the file and line number, this gets back the
previous instruction's location. There are likely corner cases where
this doesn't work, but it's better than what we have now.

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

Added more missing files required to build with 'is_debug=true' when
LLVM 10 is used as the backend.

Bug: chromium:1108382
Bug: angleproject:4861
Change-Id: I24f5686b96d04508934a59dcc3dd14b799fbd93a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46928Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

Changed the algorithm to compute the copySize value.

Earlier, in the isEntireRow && isSingleSlice case we were putting
copySize = imageExtent.height * imageRowPitchBytes which is wrong
in the case when imageRowPitchBytes is the same as
bufferRowPitchBytes, but also contains some extra padding.
For example, for copying to the whole 127 x 64 texture with RGBA8
format with bufferRowPitchBytes = 4 * 128 and buffer size =
4 * (63 * 128 + 127) will produce an assertion error.

Bug: swiftshader:152
Change-Id: If7524534ff268a70b77cfeda8611abc99f148888
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46908Tested-by: Tomek Ponitka <tommek@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Subzero requires specifying the target CPU features at construction,
and doesn't use this legacy LLVM support code.

It is conceivable that this code was putting build host specific
information into static variables, thus not producing the same binary
when built on different machines.

Bug: chromium:937268
Bug: b/155971541
Change-Id: I8934c4abfebc3901ef50edfe86a0122b1b50e319
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46689Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

The LLVM debugging API changed since LLVM 7. Updated the code to work
with the new API.

Also enabled Kokoro builds with REACTOR_EMIT_DEBUG_INFO and
REACTOR_EMIT_PRINT_LOCATION on LLVM 10.

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

Delete all code that supported using LLVM version < 10.

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

Also set the Subzero ones to use 10.0. This is only necessary so that
CMake is able to add the llvm-10.0 subdirectory, despite the target not
being built.

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

Some of the files for LLVM 10 were conditionally compiled for Debug
builds; however, two of these were also in the main source list:

${LLVM_DIR}/lib/Analysis/RegionInfo.cpp
${LLVM_DIR}/lib/Support/Debug.cpp

This lead to linker errors for missing symbols when, for e.g.,
Support/Debug.cpp was built because Support/circular_raw_ostream.cpp
was not compiled.

I decided to just fold in these few Debug-only sources into the main
list to keep it simple and similar to how LLVM 7 was being built.

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

Reactor backend: Subzero

Change-Id: I8e8af15a9b0406c9470a3e23d02345fe27740a51
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46448Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

This allows authors as well as reviewers to avoid wasting CPU cycles on
changes which require revision or won't be accepted.

Change-Id: I57946609462149d29229b613d0a4c68a21ccb154
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46548
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

0c60dc5c broke Chromium’s macOS arm64 build
(https://ci.chromium.org/p/chromium/builders/ci/mac-arm64) when it
switched the GN build from llvm 7 to 10, because the GN build of llvm
10 mistakenly omitted llvm/lib/Support/RWMutex.cpp.

Bug: chromium:1107585
Change-Id: I7b1aa82007e190c19a0ac50a09ce81ab23ba38d5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46748Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Replaces "fxb/#" with the Monorail syntax "fuchsia:#".
This updates https://swiftshader-review.googlesource.com/c/SwiftShader/+/44129.

Bug: None
Change-Id: I9dc0e617cdec2d1a8b980ee7aca2c718ce4021d6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46328
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: David Dorwin <ddorwin@google.com>

The latest version of PowerVR_Examples includes a fix that I authored to
generate files in the binary directory so that the source directory
remains clean: https://github.com/powervr-graphics/Native_SDK/pull/52
(They manually applied my changes, so it was not merged directly).

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

The _PACK32 formats have non-packed equivalents with the exact same data
layout, so there's no reason not to have them support the same features.

Also add missing switch cases to avoid debug asserts, and remove 3-byte
formats which we don't support at all.

Bug: b/158259842
Tests: dEQP-VK.*pack32*
Change-Id: Ie655571d50f1af3d97204466f9053b81e32f1490
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45908
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

https://ci.chromium.org/p/chromium/builders/ci/UBSan%20vptr%20Release

ERROR at //third_party/swiftshader/third_party/llvm-10.0/BUILD.gn:132:5: Undefined identifier.
    sources += [ "llvm/lib/Target/ARM/MCTargetDesc/ARMTargetStreamer.cpp" ]
    ^------

Bug: b/152339534
Change-Id: I59ae43c44ed22b95c836188897497723adcb9a23
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46668Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

* Fix std::shared_mutex not found when compiling with clang-cl. LLVM's
RWMutex assumes _MSC_VER is defined only when using the msvc compiler,
but clang-cl also defines it, which uses libc++ that does not define
std::shared_mutex for pre-C++17. To fix it, we also make sure __clang__
is not defined (_MSC_VER and __clang__ implies clang-cl). I will make a
similar upstream fix.

* Fix missing ___chkstk symbol linker error

* Fix "warning C4018: '>': signed/unsigned mismatch" by disabling the
warning.

Bug: b/152339534
Bug: b/161554059
Bug: chromium:1106623
Bug: angleproject:4851
Change-Id: I8639417e3ff78d82477b5ff9699f63507ec2a4ec
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46628Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

They are broken, and we now have extensive build coverage through
Kokoro.

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

Note the .clang-format config file is now incompatible with clang-format
version 8 due to the use of AfterCaseLabel, which is necessary to match
the current formatting.

Also add amaiorano@google.com as a project owner.

Bug: b/144825072
Change-Id: Ifd8ceae65245f0bc12143095ab5336f177f4a78f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43451
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

Three files were duplicated in the same source_set for LLVM 10, but with
different case:

"llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp",
"llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp",
"llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp",

"llvm/lib/DebugInfo/DWARF/DWARFCompileUnit.cpp",
"llvm/lib/DebugInfo/DWARF/DWARFExpression.cpp",
"llvm/lib/DebugInfo/DWARF/DWARFCompileUnit.cpp",

GN/Ninja doesn't like this, and it only failed on Mac for some reason
(See https://bugs.chromium.org/p/gn/issues/detail?id=180).
Split out the DebugInfo files into a separate source_set to fix this.

Bug: b/152339534
Change-Id: I294d48945ac5b47971b8387948bbd05767f7095c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46568Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

Chromium MacOS bots are at version 10.10, while the configs were
compiled on 10.13. We now pass the version to the compiler when building
LLVM, which modifies the config files to support the specified version.
In this case, it simply undefines HAVE_FUTIMENS.

Bug: b/152339534
Change-Id: I76d231660e6ee6f087bb67389a0a61abe4673740
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46549Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

When calling 'update.py fuchsia', will now build and generate for x64
and arm64. Note that David Turner (digit@) had already manually created
the configs by copying and modifying the Linux ones as part of this
change:
https://swiftshader-review.googlesource.com/c/SwiftShader/+/43851

After running update.py, I kept the Fuchsia-specific changes that were
made mainly to config.h. The diffs mainly remove unsupported targets,
and also add arm64, which was missing. Note that arm64 configs were
present in the LLVM 7 Fuchsia configs, so likely it was just an
oversight or temporary thing.

Tested by succesfully building Chromium for Fuchsia, both targeting x64
and arm64.

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

Created a BUILD.gn file for llvm-10.0, and validated that chromium
builds for x64, as well as for Fuchsia x64 and arm64. Note that as
far as we know, only Fuchsia is currently using the LLVM backend
for Reactor for arm64 builds; normal Chromium builds use the Subzero
backend.

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

When copying between buffers and textures, the bufferLayerSize didn't
take the rowPitch into account and would in most cases just use the size
of the copy.

Fix this by using bufferSlicePitchBytes for src/dstLayerSize.

Bug: swiftshader:152
Change-Id: I716f809bfa068d4836ef02366a01732fc2baa9d3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46509
Presubmit-Ready: Corentin Wallez <cwallez@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Corentin Wallez <cwallez@google.com>

Pull together documentation from various places and put into one document.
Includes some long-overdue documentation on how the code coverage data is processed and compressed.

Change-Id: Iddf2094aff1f3804cd1ea19414e40da3b7cae163
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46468Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Also moves the -DHAVE_GRALLOC cflags away from the
host build as hosts do not have gralloc and mapper
3 does not have a header only library available.

Bug: b/157902551
Test: launch_cvd w/ Cuttlefish ashmem Gralloc0
Test: launch_cvd w/ Cuttlefish minigbm Gralloc3
Change-Id: I99da611a2b72f9d39df32ab9883dc52f2c081217
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46408
Presubmit-Ready: Jason Macnak <natsu@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Reactor backend: Subzero

Change-Id: I45ec1380da88f8602b5d89d89df5807fbd4b0a43
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46388Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

X11/Xlib.h defines Bool as a macro, which clashes with Reactor's Bool
class. This X11 header is also included by vulkan.h, vk_icd.h, and
EGL/eglplatform.h

Previously we undefined Bool in various places. It's not possible to
just undefine it in Reactor.hpp because one can have headers following
the inclusion of Reactor.hpp which redefine it (note our convention is
to include platform headers after project headers).

Since X11 is only needed in select places related to the windowing
system, we can instead avoid the use of these headers in other headers,
and only include them in .cpp files where necessary. Note that
vulkan_core.h contains the whole plaform-independent Vulkan API, so it
should be used instead of vulkan.h for all non-WSI code.

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

Surface::decodeASTC() was empty, and ENABLE_ASTC hard-coded to 0, so we
never actually supported ASTC for OpenGL ES.

We won't need it in the future since this legacy code is deprecated and
set to be replaced by SwANGLE (which supports ASTC LDR at the moment).
Also note ASTC LDR doesn't become mandatory until OpenGL ES 3.2, and
this legacy code lacks compute shaders to even support ES 3.1.

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

While e.g. "CmdImageToImageCopy" was slightly more explicit, it can
leave one searching for the vkCmdImageToImageCopy API call.

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

This passes all the non-sparse BC6h format tests in dEQP.

Bug: b/151203718
Tests: dEQP-VK.*bc6*
Change-Id: I5dacbc07bb54ff4fc384db974feaf7cfd0055e96
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45571
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Instead of updating images every time we write to them,
this cl adds a dirtiness mechanism, which will mark an
Image object as dirty for specific unique subresource
regions and then only actually perform the required
task (cube border update, decompression, ...) once the
image memory is accessed for reading.

Bug: b/159045555
Change-Id: I791a69529e4c2e78aa6562251020aa0bf978bd01
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45188
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

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

Only a single layer was being copied in the case of 2D array to 2D array
copies. In the case of 2D array to 3D image copies, or vice-versa, the
extent depth is the same as the layer count as per the Vulkan
requirements, but this relied on the layer pitch to be the same as the
slice pitch, which isn't true when layers contain multiple mipmap
levels.

Both issues have been addressed by adding a loop to iterate over the
layers, adjusting the pitch in case a layer is copied to/from a slice.
The inner loop for copying slices to slices is used for 3D image to
3D image copies, and for multisample 2D image to multisample 2D image
copies (which can also have multiple layers).

Also clarify the Image::getLastLayerIndex() and getLastMipLevel()
methods should not be used for VkImageSubresourceLayers structures used
by copy, blit, and resolve operations (they require explicit layer and
level counts). VkImageSubresourceRange is only for image view creation,
memory barriers, and clear operations, which accept the use of
VK_REMAINING_ARRAY_LAYERS and VK_REMAINING_MIP_LEVELS.

Bug: b/159666631
Bug: swiftshader:152
Change-Id: If998795e2b5e55950cc9fa23373a7300b6d2e0fc
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46132
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>