The Vulkan loader somewhat recently introduced a requirement that
clients must opt-in to using portability implementations of Vulkan (such
as MoltenVK). Since there is no native Vulkan driver for macOS (and
therefore no alternative), unconditionally enable the portability
enumeration extension there.
Bug: angleproject:8229
Change-Id: I24f0f24e25abd277855ed9ac4de370cfb47d3266
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4639495
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Steven Noonan <steven@uplinklabs.net>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Steven Noonan <steven@uplinklabs.net>
The previous CL added the feature of freeing garbage memory in the
event of device OOM. However, it was for image allocations only.
* Extended finishing commands and freeing the garbage to buffers.
* Added unit test to allocate buffer after freeing memory space on the
device.
Bug: b/280304441
Change-Id: I540b27a41b34d1ceb1cd3119213341c9f290ea38
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4540209
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Currently image allocations fall back to system memory in case of
a device OOM. However, in some cases, it is also possible to gain
some memory by freeing garbage memory from the device. This allows
us to keep the allocation on the device memory.
* Updated the image allocation fallback, so we will try cleaning the
garbage memory through the renderer before retrying the allocation.
* finishOneCommandBatchAndCleanup() in RendererVk, which will call a
similar function in its CommandQueue. It will be called until there
are no more in-flight submissions.
* The existing finishOneCommandBatchAndCleanup() in CommandQueue has
been renamed to finishOneCommandBatchAndCleanupImpl().
* Updated the flags used for VMA image allocations. If any device memory
is freed after garbage cleanup to make enough space for the new
allocation, it will take precedence over the system memory.
* Added unit tests in which a new image allocation could happen on the
device after freeing the garbage memory.
* They use a 2D texture and a 2D texture array for garbage.
Bug: b/280304441
Change-Id: Ia5e605e180833b44af8c77550ab1b0b8ba21724e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4547941
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
While looking at disassemble of
DescriptorSetDescBuilder::updateOneShaderBuffer() function, I noticed
that there are a lot of CPU cycles spent in FastMap::operator[]. What
happend here is that we are increasing size one by one as we build
descriptorSet, and that hit `if (mData.size() <= key)` case and we end
up resize the underline FastVector, and that resize also initialize the
element with zeros, which immediately overwrite by actual data. Since we
actually know the eventual size of
DescriptorSetDescBuilder::mDesc/mHandles/mDynamicOffsets, we could just
switch to angle::FastVector which will avoid this check size and grow
every time we write to it. This CL switches the use of FastMap in
DescriptorSetDescBuilder to FastVector. The only trick we need to watch
out is that previously the new elements are always zero filled and now
it does not. So we need to make sure we write every field of structure.
This CL also renames WriteDescriptorDescBuilder to WriteDescriptorDescs
since when it is read only we are passing it as const reference already,
there is no added advantage to have two classes.
Bug: b/282194402
Change-Id: I06a063cc51585fc17fbf0d5aa916b9aa0ab88dd4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4581881
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Currently if we try to define a 2D texture array in ES2, a crash
occurs during its validation. Since texture3DOES only adds support to
3D textures, we should make sure the validation only passes if ES3 and
above are used.
* Added check for 2D texture array usage in validating glTexImage3D().
Bug: angleproject:8213
Change-Id: Ib477d8b6eec89c35d605a1b575bfb5519d19452e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4618955
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Android CTS and Khronos CTS use different set of
dEQP tests. android/cts contains mustpass lists
for Android CTS. We have test coverage in the
Android CTS in Android testing infra, and we would
like ANGLE standlone deqp test runner to cover the
Khronos CTS. Update the dEQP-EGL test runner to use
the mustpass list that Khronos CTS uses.
Since the test lists changed, some tests in
expectation files are no longer needed, as they
are not within Khronos CTS mustpass list. Keeping
them in the expectation file will cause test runner
exception as the test runner does check if the test
listed in the expectation file is in the mustpass list.
Bug: b/286921997
Bug: angleproject:6277
Bug: angleproject:7506
Bug: angleproject:6528
Change-Id: I7851b854322985f564cbb56d804f04f663d947aa
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4619627
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
1. Always upload color values encoded in sRGB colorspace for
sampling tests and linear colorspace for rendering tests.
Depending on attribute list, the test will either expect
color decoded in linear space or sRGB color value as is
2. Add helper functions that determine expected output color
for a given attribute list and EGLImage usage
Refactor TEST and helper functions to account for the above updates
Test: ImageTest*_Colorspace*
Bug: angleproject:3756
Change-Id: I54ae22b2d379e6fdfa04429849de5efe9684caf4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4643452
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Overwritten features were never reset even if a display was
terminated. On platforms that reuse displays for all tests
in the end2end suite, overridden feature would leak into
subsequent tests causing unexpected failure.
Bug: angleproject:8235
Change-Id: I1b359bc762a2bca8db4e4dbc7a587604e5bd6a5b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4643453
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
With the conversion of the interface variable info map keys to SPIR-V
ids, there is no longer a benefit to bucket resources by their type.
This change removes this bucketing and flattens the map.
Bug: angleproject:7220
Change-Id: If83cb02ca9e91f72dddb2deb7313fee40f9f06c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4632577
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
The shader interface variable map had a "resource index" -> info map to
optimize descriptor set building. That avoided hashing the resource
name when the rest of the map was name-based.
With the map using SPIR-V ids now, there is no reason to maintain this
map; SPIR-V ids can be used to look up the info just as efficiently.
Bug: angleproject:7220
Change-Id: I619783dce558a59184955cc314c1f41e6733f1b7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4630728
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
When creating a new pipeline cache and the blob cache doesn't have
a matching one we can load, we unintentionally skipped serializing it to
the blob cache until the pipeline cache state changed later on.
Bug: angleproject:8230
Change-Id: If86d1bd169a63da9f9a394284a754bccb7d52e20
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4639496
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
The most important part of this is unloading the libvulkan handle. We
open the handle in ::initialize but we were previously only unloading it
in ::~RendererVk[1]. Since a DisplayVk (and RendererVk) are not
destructed in between context creations, this meant that the libvulkan
library handle reference count only increased, never decreased.
[1] Which, incidentally, never gets invoked, ever. We create Display
instances and they live forever in a static structure and we only
::initialize/::terminate them.
Bug: angleproject:8225
Change-Id: I03da9b19f0c4ae3b5efacd07880aadb7ee77ebf5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4636882
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
This change removes duplicate entries added in the shader shader
interface variable maps. One level of arrayness (indexed by shader
type) is removed from these maps as now there is only a single entry
per linked resource/etc.
Bug: angleproject:7220
Change-Id: Ibf2d06a0e1f68e68797c2066f36e14cb9e667f77
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4628677
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
The translated metal shader source is quite large and we store copies
in both ProgramMtl and mtl::LibraryCache.
Instead, store the source in shared_ptrs to immutable strings. This has
a nice side effect of simplifying the cache keys for mtl::Library cache
and avoiding string copies.
This saves about 4% GPU process memory.
Since these strings are rarely accessed, the overhead of shared_ptr is
not a concern.
Bug: chromium:1329376
Change-Id: I507529ff1e25cc6aafead272fc9bb6ab0b8dbe88
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4614361
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Quyen Le <lehoangquyen@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Framebuffers have a much more detailed "reason" string for framebuffer
completeness errors. Make sure that reason is printed when a draw call
fails due to incomplete framebuffer.
Rework how draw validation errors are stored to keep the extra GL error
enum.
Bug: chromium:1455725
Change-Id: I5984452c5aab4f8ccb73d43bd63bca1aae53e847
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4632578
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
ensureIncompleteTexturesCreated is called in every syncState and
initializes all types of incomplete textures, even when they are not
used.
Skip it entirely. ContextMtl::getIncompleteTexture already lazily
creates the incomplete textures, per type.
This saves about 1mb (~5% of ANGLE's allocations for Chrome) of
malloc'd memory per context.
Bug: chromium:1329376
Change-Id: I14ab7098ce2e486383d1d0d41039f0e526755878
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4615190
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Quyen Le <lehoangquyen@chromium.org>
Previously, resource binding assignment was done as such:
```
for each shader stage
assign bindings to textures
assign bindings to blocks
assign bindings to images
etc
```
To deduplicate bindings when the same resource was used in multiple
stages, a map was used, keyed by the resource's name, to detect when an
already visited resource is encountered in a future stage. This was
both inefficient and unnecessarily complicated.
With this change, resource binding assignment is done as such:
```
for each texture
assign one binding to all shader stages
for each block
assign one binding to all shader stages
for each image
assign one binding to all shader stages
etc
```
The aforementioned map is removed.
Because the resource bindings are now changed, the rest of the code
(which sets up the pipeline layout, updates descriptor sets, sets
dynamic buffer offsets, etc) are all updated to follow the above
pattern. As a result, nested loops are avoided and duplicate entries in
the variable map are never visited.
Bug: angleproject:7220
Change-Id: Iaff7b5f8b2bada8ac5078d21e5c790bf0d27aca7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4622011
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
On outdated (but recent) AMD drivers, the Windows-only Vulkan extension
VK_EXT_full_screen_exclusive appeared to be implicitly enabled and set
to VK_FULL_SCREEN_EXCLUSIVE_APPLICATION_CONTROLLED_EXT mode. Even though
ANGLE did not enable or interact with this extension at all, the driver
was incorrectly returning VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT
error codes on various swapchain operations when the full screen window
focus was lost (i.e. alt-tab out and back in). Naturally, ANGLE was not
expecting these error codes and did not know how to handle them.
Depending on where the errors occurred, ANGLE might crash or retry
creating the swapchain repeatedly.
Treating the unexpected VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT
error code as VK_ERROR_OUT_OF_DATE_KHR/VK_SUBOPTIMAL_KHR was not
sufficient, because the driver would repeat the error on every swapchain
operation, apparently expecting the error to be handled by
a vkAcquireFullScreenExclusiveModeEXT call (even though that would make
no sense, since the extension was not enabled).
The incorrect driver behavior was reported to AMD and was fixed in
recent driver releases. The earliest driver I've tested and know to be
working is AMD's Adrenaline driver version 23.5.2
(VkPhysicalDeviceProperties calls this driverVersion 2.0.262/0x800106).
The last known bad version was 0x8000e9.
The simplest workaround on these older AMD graphics drivers is to
explicitly enable the extension, but set it to
VK_FULL_SCREEN_EXCLUSIVE_DISALLOWED_EXT mode. On newer drivers we do not
need to do anything with the extension and can ignore it.
Bug: angleproject:8215
Change-Id: I7c58d47a0350f4b0bc1a77f200c1e2f72fcde8d8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4627279
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
On drivers before R530, there are some transient visual glitches in
rendering when using VK_EXT_graphics_pipeline_library. Basically you
might see correct renders for a few frames, very incorrect renders for
about 10-20 frames, and then it would render correctly from then on.
This problem went away either at R530 or slightly after. This change
sets the minimum version to R531, which is the first version I observed
behaving correctly.
Bug: angleproject:8218
Change-Id: I7af4f74c1469ecf2306dec0cab9062eff2ec5f2c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4627277
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Not doing so results in VVL errors (you need the GPU-assisted validation
preset enabled to see this error):
[ VUID-VkDrawIndexedIndirectCommand-firstInstance-00554 ]
The drawIndirectFirstInstance feature is not enabled, but the
firstInstance member of the VkDrawIndexedIndirectCommand structure
at index 1 is not zero The Vulkan spec states: If the
drawIndirectFirstInstance feature is not enabled, firstInstance must
be 0
Bug: angleproject:8220
Change-Id: Ia43036584b85e4a7d9c3fcaf793be94b965f708f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4627278
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
