To allow the creation of multiple EGLDisplays on the same graphics
device, we need a value to key for the display cache. When the
display key is specified, the cache will return a new display for
that key, even if there is an existing display on the same graphics
device.
Bug: chromium:1251724
Change-Id: I55e169776770734fc33b8bc8e1265ea6f7472fe3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4255730
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
This CL is mechanical change only and limited to CommandProcessor class.
It renames mTasks to mTaskQueue, renames mWorkerMutex to
mTaskEnqueueMutex, rename mSubmissionMutex to mTaskDequeueMutex.
Bug: b/267348918
Change-Id: I7a8c6820eb3bd27d4e6aacb1abe7275f3c0ec5c5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4255807
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
These are vulkan commands submitted between
glClear() and glReadPixels() when the EGL_RENDER_BUFFER
is EGL_SINGLE_BUFFER (ImageLayour is SharedPresent):
```
vkCmdClearColorImage()
vkCmdPipelineBarrier: (
VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,//srcStageMask
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,//dstStageMask
VK_ACCESS_MEMORY_WRITE_BIT,//srcAccessMask
VK_ACCESS_MEMORY_WRITE_BIT|VK_ACCESS_MEMORY_READ_BIT//dstAccessMask
)
vkCmdCopyImageToBuffer()
```
This means that operations at the bottom of pipeline
in vkCmdCopyImageToBuffer() need to wait for operations
at the top of pipeline in vmCmdClearColorImage(), which
translates to vkCmdCopyImageToBuffer() does not have
to wait for vkCmdClearColorImage() to finish.
Even the dstAccessMask ensures that
vkCmdCopyImageToBuffer() will invalidate cache before
copying image, it is possible that it will retrieve the
old Framebuffer color attachment data as the
vkCmdClearColorImage() has not finished.
This CL fixes the bug by making the srcStageMask to
be VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT and the
dstStageMask to be VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,
when the ImageLayout is SharedPresent.
This ensures that vkCmdCopyImageToBuffer() waits for
vkCmdClearColorImage() to finish.
This CL also addresses similar issue in some other
rx::vk::ImageLayout items in kImageMemoryBarrierData.
Bug: b/264420030
Change-Id: If47ab071afaf96e396357cb0f50131339fa58509
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4198476
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
d3dcompiler_old.dll was retained for compatibility with Windows 7 but
can now be removed. It will be missing from future toolchain packages
and we no longer need code to handle it.
This also updates a doc page to change python to python3.
Bug: chromium:1416385, chromium:1385856
Change-Id: I80c9b6dec887bc403f6fe3dac4007acb1f164ea6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4251620
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
So far calls involving EGLSync were not tracking the actual
sync objects, and this may lead to race conditions in
multi-threaded and multi-context scenarios.
This CL adds the type EGLSyncID and some specialized code
handling of egl::Sync to distinguish EGLSync from the already
existing GLSync objects in order to track them separately.
Bug: angleproject:7911
Change-Id: I91b188a41069bc0620f51c55ee516d23b55bdd38
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4200095
Commit-Queue: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Bugs:
- items resources may not be freed after resizing to a lesser size.
- reusing capacity may use old values for the new items.
Fixed by resting removed items to default values.
Alternative fix is to disallow dangerous operations on non trivially
constructible/destructible types.
Bug: angleproject:8021
Test: angle_unittests --gtest_filter="FastVector.DestroyOldItems"
Test: angle_unittests --gtest_filter="FastVector.ReuseCapacity"
Change-Id: I8bc616a9476608c9301e3f7af3a0d504e7e2d2db
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4249960
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
When created C traces the value "nullptr" is not defined, so
emit NULL instead, because this is supported in both, C and C++.
Bug: angleproject:8018
Change-Id: I77584c462b1b02df39871929c1979d7ee7624361
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4254388
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
Initialize "mRefCounted" in member initializer list to avoid unnecessary
initialization with "nullptr" provided by the default member
initializer.
Optimizer will eliminate extra store in release builds but not in debug.
This change is more for code cleanness than for performance.
Bug: None
Change-Id: I1127a543468bb4138ae12d8941af27591ec4a2e8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4251638
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Update the Metal library cache to be thread safe. Change
absl::flat_hash_map back to std::unordered_map because the value types
now contain a mutex which must not move.
Only generate async compilation tasks for shaders that were not already
compiled and in the cache.
Collapse some of the link methods in ProgramMtl that only had one call
site. All linking is now done in ProgramMtl::link and
ProgramMtl::load.
Support disabling parallel linking using the new
enableParallelMtlLibraryCompilation feature.
Bug: chromium:1385510
Change-Id: I71ba71a34d994066729df7e4170911f88c89de4a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4234153
Reviewed-by: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
This test is not destroying the context properly, which leads to
eglTerminate(dpy) not actually destroying the RendererVk. When the next
test app runs, it calls RendererVk::initialize again and calls
volkLoadInstance(mInstance). Because the previous RendererVk object is
still there, and the two CommandQueue shares the same volk instance,
writing to volk function table causes tsan to complain that other thread
is still using the old function pointer that now gets overwritten.
The test really should clean up properly here in order to have other
test to continue to run.
Bug: angleproject:7602
Change-Id: I93cd2439194aba9f28ce478aaf79ae8b81c6426b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4249984
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Calling "checkAndPopPendingError()" without "mSubmissionMutex" lock
may cause situation, when new error is added to "mErrors" right after
the call. This new error may be for the work we are waiting for, and
it processing will be skipped.
Current CommandProcessor error handing should be rewritten in the
future anyway, but I think this minor error should be addressed now.
Bug: b/267348918
Change-Id: I65c49f7dc8e1984696d464c38f13fcdce93337bf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4245421
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
- bug: "mSize" used to end the loop but also changed inside the loop by
call to the "pop()" method.
- refactoring: "mBackIndex" name is not correct, because variable
references to the "index for next write", in other words - to the
element past "back" (last written). Renamed to "mEndIndex" to match
the "std" terminology.
Bug: b/267348918
Test: angle_unittests --gtest_filter="FixedQueue.Clear"
Change-Id: Ic65291a7ff2ff6f4eed223ca80fef187e42df3e5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4245420
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
This commit:
Vulkan: Switch CommandQueue::mInflightCommands to FixedQueue
ad81cc9550
changes how SuballocationGarbage is processed in the "submitCommands()"
method. New logic allows clearing entire "mInFlightCommands" queue.
In case if this change was intentional, it should also remove this text
from the comment:
// But if there is only one command buffer in flight, we do not wait
// here to ensure we keep GPU busy.
Bug: b/267682377
Change-Id: Ia280c468c79f45dd44791cff09887982094521e3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4245422
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
This reverts commit 968041b547.
Includes the following patches:
git revert -n 995db1f66b \
9a6c90c8f8 \
dbd47e3785 \
369b320f92 \
4abae6f975 \
968041b547
Several conflicts with top-of-tree were resolved during this revert.
The aim is to reland this with additional code which will reduce the
amount of excess buffer memory allocated, and release the resources
associated with temporary buffer allocations.
Bug: angleproject:7544
Change-Id: Ib7a6bc2ab1c2f23cb43112cd980106e2898c3826
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4240556
Reviewed-by: Kimmo Kinnunen <kkinnunen@apple.com>
Reviewed-by: Gregg Tavares <gman@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
This change makes sure instance extension entry points are loaded right
after the instance is. Previously, this was done after all features are
initialized, including device features, but the code that decides the
device features was using the instance entry points.
Bug: angleproject:7959
Change-Id: I6869f40261eec7a3146c9e0e05b3fc139bc9223a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4247097
Commit-Queue: Ian Elliott <ianelliott@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
When the dump_shader_source is enabled, dump a small file for each
program link containing which shaders were attached to the program.
This allows us to build perf tests knowing which shaders can link
together.
Bug: angleproject:7760, chromium:1385510
Change-Id: I0713e9f04cc157c3a3eeeec6d597db27b08575d1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4214011
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
To improve readability, code moved from class body closer to the tests.
Bug: angleproject:7995
Change-Id: I2c0aef593b28cfffe2b04de308274d0007d863c5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4245177
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
This was observed to be nullptr in some builds and assumed to be a
driver bug. However, this was due to a bug in implementation where the
code that was supposed to load the entry point was actually loading
another entry point.
This was fixed in
https://chromium-review.googlesource.com/c/angle/angle/+/4224582
Bug: chromium:1273344
Change-Id: I8c2003b322878fcab9282c793a8b1901d5d8e7a5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4227990
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
If a timeout occurs while waiting for the VK queue to be idle during
context destruction, there is no way to safely delete the resources
without potentially crashing as the driver is still reading them.
Instead, wait forever and let Chrome's watchdog tear the process down.
Bug: chromium:1223346
Change-Id: Ifa91465270f54b62a5ead88e8f26b3315072c380
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3430243
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Extensions are now grouped based on promotion-to-core status, and
initialization code is generally cleaned up. ANGLE currently doesn't
attempt to use a core version above Vulkan 1.1, as extensions are always
assumed to be exposed even if promoted to core in later versions.
With this change, it would be simpler to use a newer core version if
ever necessary.
Bug: angleproject:7959
Change-Id: Ia5fd3e06c18f7289e9e5a63af0f039a6dc89c687
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4224582
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
We have to capture the case when only the binding index is not
at the default value.
Bug: angleproject:7912
Change-Id: Id08b20788422694db60f38c6e0b8b4a9191890c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4143841
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Gert Wollny <gert.wollny@collabora.com>
The supported texture format tables would have entries for
a signed or unsigned internal format and matching type.
The texSubImage variants do not communicate the sized internal format,
rather unsized format type. Data parameters are validated based on
format, not internal format. For these, the signed variants were
missing.
Add texture format table entries for signed types that match the format
parameters.
Add a precautionary validation case so that future such bugs would not
pass the control flow forward, into the copying phase.
Fixed: angleproject:8014
Change-Id: I5b00cca8672691fdb953f62093d62feaa724db99
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4238881
Commit-Queue: Kimmo Kinnunen <kkinnunen@apple.com>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Auto-Submit: Kimmo Kinnunen <kkinnunen@apple.com>
Some of the vendor checks in the EGL_EXT_image_dma_buf_import_modifiers
enablement logic disable the extension on older Mali devices while
Chrome depends on the presence of this extension, even if the
implementation is no-op'ed.
Refactor the logic into DisplayEGL with a tri-state:
* Extension exposed and forwarded to the driver
* Extension exposed and no-op'ed (Mali)
* Extension not exposed (ARM)
Bug: angleproject:7664
Change-Id: Idca7bb609423366779a65cd65093c9d5a65f0c19
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4241483
Reviewed-by: Brian Ho <hob@chromium.org>
Auto-Submit: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Brian Ho <hob@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
A fix in the spec made it clear that the pipeline layout is always
necessary when creating the linked pipeline. This change removes the
comment that marks it as a driver workaround.
Bug: angleproject:7369
Change-Id: I7d068d330a7517fbc6e064fe2e796c2c53f6b859
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4241397
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Original implementation used Unprotected submission unconditionally.
In case of protected content/commands this may cause undefined
behavior.
New test works OK despite the bug.
VVL also did not show error, but should report:
VUID-VkSubmitInfo-pNext-04120
If the pNext chain of this structure does not include a
VkProtectedSubmitInfo structure with protectedSubmit set to VK_TRUE,
then each element of the pCommandBuffers array must be an
unprotected command buffer
Also from spec:
protectedSubmit specifies whether the batch is protected.
If protectedSubmit is VK_TRUE, the batch is protected.
If protectedSubmit is VK_FALSE, the batch is unprotected.
If the VkSubmitInfo::pNext chain does not include this structure,
the batch is unprotected.
It is a bug in VVL. It ignores check entirely if VkSubmitInfo::pNext
chain does not include VkProtectedSubmitInfo structure.
Bug: angleproject:3966
Test: angle_end2end_test --gtest_filter="EGLProtectedContentTest.ProtectedContextWithProtectedMutableRenderBufferWindowSurface*"
Change-Id: I0e0762e5fdfe19ce6c2184a36d057a95c2c79f00
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4232115
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Recently implemented fix has a problem:
When using "asyncCommandQueue", wait semaphores flush performed in
the context thread, while submit in the async thread. Both operations
protected by the mutex, so there is no data race or other UB.
It is a potential performance problem: submit operation may attach
wait semaphores prematurely, before corresponding commands flushed into
the primary command buffer.
Fix adds "CustomTask::FlushWaitSemaphores" to ensure wait semaphores and
commands flushed in order.
Bug: angleproject:7995
Change-Id: I7d3cfad867c59d3cd0a5c0bb3f81ae8d98238362
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4231844
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
VkQueueSubmit and VkQueuePresent could potentially take long. Right now
it is called while holding CommandQueue::mMutex lock. In previous CL we
moved mInFlightCommands to FixedQueue, which allows push/pop occur
concurrently. This CL moves queueSubmit and queuePresent to not take
mMutex but uses mSubmissionMutex. This allows other thread to
checkCompletedCommands etc while we doing submit/present.
The tricky part is that mPrimaryCommands is shared between all contexts.
It can contain commands from different contexts, thus the vkQueueSubmit
ordering must strictly follow the order of RendererVk::submitCommands()
call. The mMutex and mQueueSubmitMutex are managed in a way that does
the lock relay so that we always have a lock covering the
submitCommands call all the way to vkQueueSubmit.
Bug: b/267682377
Change-Id: Ic556cd4c64d334ad1cfc68942b803e401c6b0cc1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4218198
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
This CL is mostly a clean up and refactoring and prepare for next CL. No
actual functionality change is expected. It added a new function for the
post queueSubmit logic. It moves CommandQueue::queueSubmit() into the
same location as queuePresent.
Bug: b/267682377
Change-Id: I240934dc4db06ce1277955938427a9e257211277
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4226006
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
This reverts commit e6662832af.
After the commit
61728827d2,
we no longer depends on git hash to determine
if the program binary cache is valid.
The reverted commit was added to handle
unknown git hash. Android build infra does not
guarantee access to git, and we needed
GetANGLEHasBinaryLoading() check because we
can't tell if ANGLE program changed if git hash
remains "unknown" across different builds.
Now that we used a different hash
ANGLE_PROGRAM_VERSION as the cache key, which
generates from a list of code files that affect
program binary content and it won't be unknown
on Android build, we can revert the commit and
rely on ANGLE_PROGRAM_VERSION to reject invalid
program binary cache.
This fixes the dEQP test
dEQP-GLES3.functional.shader_api.program_binary.
simple.uniform_reset_on_binary_load, which failed
because the GetANGLEHasBinaryLoading() is stopping
Program::loadBinary() due to "unknown" git hash
on Android build.
This CL reverts most of the original commit,
cleans up unused macros and variables,
and reserves the change in program::loadBinary()
that returns incomplete if binary format is not
GL_PROGRAM_BINARY_ANGLE. This CL also reserves the
changes in
dd8021d98c
in case Sumsung parter still needs them.
Bug: b/258445879
Change-Id: Ia4380de9362f7b8bed6de6a54943bec6600cb76b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4219368
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Required for future commits.
Details:
- Fixes possible stale result in "CommandProcessor::mSwapchainStatus"
after WindowSurfaceVk destruction.
- Fixes possible dead-lock when the old "getLastPresentResult()" method
might be called more than once.
- New implementation allows waiting multiple times
(and multiple threads) for the same Present result.
Before commit:
31c4093651
Vulkan: Rework present semaphore recycling
There was assert in CTS:
dEQP-EGL.functional.swap_buffers_with_damage.resize_before_swap.*
Assert failed in ~SwapchainCleanupData (../../src/libANGLE/renderer/vulkan/SurfaceVk.cpp:669): swapchain == VK_NULL_HANDLE
Because of the stale "CommandProcessor::mSwapchainStatus"
and a race-condition as the result.
The "Vulkan: Rework present semaphore recycling" did not fix
the problem, but rather changed undefined behavior symptom.
Bug: None
Change-Id: Idf08a29265a43c711941b142001eb4380e2aa2b6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194184
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>