|
f51170b3
|
2024-11-21T16:30:40
|
|
Enable GL_KHR_texture_compression_astc_hdr
Vulkan supports GL_KHR_texture_compression_astc_hdr,
so this extension can be enabled in Angle.
Bug: angleproject:379186304
Change-Id: I438a120c3f884a7eefcd883ad71abf68f81cb473
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6038457
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
01dee1cb
|
2024-10-14T15:04:28
|
|
Add implementation for GL_EXT_texture_storage_compression
Bug: angleproject:352364583
Change-Id: I3dab4c68d5d0206d681e165e991217bd3de8eeb6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6011055
Auto-Submit: Neil Zhang <Neil.Zhang@arm.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
cecefe53
|
2024-11-21T22:11:17
|
|
Vulkan: Improve recreateSwapchain() error handling
The `WindowSurfaceVk::recreateSwapchain()` method may fail in many
points. After failing, state of `WindowSurfaceVk` may become invalid,
causing undefined behavior.
Invalid state examples:
- Skip adding `cleanupData` into the `mOldSwapchains` while
`mPresentHistory already cleared (resource leak).
- `mSwapchain` may remain `VK_NULL_HANDLE` after the failure.
- `lastSwapchain` may be not retired, causing subsequent swapchain
creation to fail.
Change adds `mLastSwapchain` member to continue tracking last created
swapchain during the `mSwapchain` recreation process until it is
retired. This process now may span multiple API calls. The `mSwapchain`
pointer is invalidated as soon as recreate starts - to indicate that we
do not have usable swapchain and still need to create one.
Notable difference with the old code is that old swapchain and present
history are now collected into the `mOldSwapchains` after new swapchain
is created (or old swapchain is retired in case of a failure). Because
of this, code can now be simplified and easily refactored into a
separate method. The `kMaxOldSwapchains` is now also checked after old
swapchain is collected - this is to prevent resource leak if `finish()`
fails. Added `cleanUpOldSwapchains()` call to reduce a chance of hitting
the `kMaxOldSwapchains` limit.
Change also renamed `presentOutOfDate` parameter where it does not
always make sense. As a side effect, fixed a bug when calling
`prepareForAcquireNextSwapchainImage()` with true, is then replaced
with false in the `computePresentOutOfDate()` call.
Bug: angleproject:380234227
Change-Id: Ie6d85c1b9760cda68c8fc9368235756659a9bdac
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6040159
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f458f865
|
2024-11-12T16:52:42
|
|
Vulkan: Update AcquireNextImageUnlocked() implementation
Main goal of this change is to simplify acquire next image operation
state change tracking.
Key members before this change:
1. `mAcquireOperation.needToAcquireNextSwapchainImage`
2. `unlockedAcquireResult.acquireSemaphore`
Possible states:
1: 2:
false NULL -> image is acquired or no need
true ANY -> need to prepare for and do unlocked ANI
false HANDLE -> need to process ANI result
Only `mAcquireOperation.state` is used after this change.
Possible states:
Ready -> image is acquired or no need
NeedToAcquire -> need to prepare for and do unlocked ANI
NeedToProcessResult -> need to process ANI result
Value of `unlockedAcquireResult.acquireSemaphore` is now only used
as semaphore in the post process and not as boolean, indicating that
result needs processing.
Change adds a lot of ASSERTs to protect from invalid scenarios. In order
for these ASSERTs to work as expected, `deferAcquireNextImage()` is now
called regardless if swapchain is out-of-date or not.
Another functional change is that `postProcessUnlockedAcquire()` does
not mark image as processed at the start and then defers ANI in case of
a failure (so the next ANI fail again), but instead keeps the current
state (NeedToProcessResult) allowing failure to be processed again
without repeating ANI call in case if there will be no swapchain
recreation. State is set to `Ready` only after processing is successful.
Bug: angleproject:42265346
Bug: angleproject:42266579
Change-Id: I4a6a66fa3b6f25a788a8959eff5848b7ec5bdd27
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6018094
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
ea86503c
|
2024-11-20T19:47:49
|
|
Vulkan: Remove vkAcquireNextImageKHR multi-threading support
Currently, it is not possible to call `TryAcquireNextImageUnlocked()`
from multiple threads. However, original implementation added
multi-threading support for future use.
Possible future use:
- First thread (where Surface is current) calls
`eglPrepareSwapBuffersANGLE()` which will call
`TryAcquireNextImageUnlocked()` in the unlocked tail call (without the
share group lock).
- Other thread (where shared Context is current) calls some EGL/GLES
API under the share group lock, that may cause calling
`doDeferredAcquireNextImage()` on the Surface from the first thread.
Calling this method may call `TryAcquireNextImageUnlocked()` under the
share group lock, while it is also called from the first thread in the
unlocked tail call. Calling `doDeferredAcquireNextImage()` may also
cause swapchain recreation.
Taking into account above scenario, current implementation has following
bugs:
1. Possibility to recreate the swapchain from other thread, while first
thread is going to or calling the `TryAcquireNextImageUnlocked()`
function:
a) Other thread may call `prepareForAcquireNextSwapchainImage()`
because `NeedToProcessAcquireNextImageResult()` is still false
until first thread finishes `TryAcquireNextImageUnlocked()` call.
Also, checking `NeedToProcessAcquireNextImageResult()` from other
thread is not thread safe.
b) Other thread finished `TryAcquireNextImageUnlocked()` first, but
with `VK_ERROR_OUT_OF_DATE_KHR` error. First thread still did not
get the chance to call this function because of OS's thread
scheduling delays. Other thread will set
`needToAcquireNextSwapchainImage = true` and will start to
recreate a swapchain. At this time, first thread will start
executing `TryAcquireNextImageUnlocked()`, and because bool is
true - it will actually perform ANI during recreate from other
thread.
2. Possibility to call `TryAcquireNextImageUnlocked()` with old
swapchain. This is similar to (1), but this time call is delayed
after swapchain is recreated.
Since above scenario currently is not possible and the described future
scenario is unlikely to ever happen, instead of fixing above problems
this CL removes the multi-threading support to simplify the code and
make these bugs N/A.
Change removes word "try" from structures, members, and functions
because without multithreading there is no need for that and just adds
unnecessary complication.
It also removes most of the "share group lock" mentions because now this
information is irrelevant and may cause confusion. What is relevant is
that `AcquireNextImageUnlocked()` MUST only be called from a thread
where Surface is current and only CAN access members that is only ever
accessed from this thread (regardless if the lock is taken or not).
For example, if in the future `unlockedAcquireResult` will be accessed
from other thread but with the share group lock held, while
`AcquireNextImageUnlocked()` will still only be called from the current
thread - then this will be a race condition.
Bug: angleproject:42265346
Bug: angleproject:42266579
Change-Id: Ie9be408c0a3b3c1f37ec80727ce5ad2cb8932dad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6018093
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
6b9b8239
|
2024-11-21T15:56:40
|
|
Vulkan: fix un-initialized mCompatiblePresentModes
When VK_EXT_swapchain_maintenance1 is supported but
VK_EXT_surface_maintenance1 is not, mCompatiblePresentModes has no
chance to be initialized.
So need to set it up in such case.
Bug: None
Change-Id: I38ac6d9da3d6cebf2effcdcd74084a53d68a32c2
Signed-off-by: Jiawei Gu <gujiawei.will@bytedance.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6040834
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
70d1ef67
|
2024-11-20T11:34:39
|
|
Vulkan: Ensure onFramebufferBoundary is called for offscreen
There is peak memory regression observed from crrev.com/c/6022549. What
I suspect happening is that for offscreen or single buffered case,
glFlush/glFinish is called but bail out because it already submitted or
deferred. So we end up not calling onFramebufferBoundary(). This CL
ensures we always call onFramebufferBoundary from these two functions
for single buffer or offscreen.
Also fixed a bug when onSharedPresentContextFlush is called we may end
up calling onFramebufferBoundary.
To make API names consistent, existing flushImpl() is renamed to
flushAndSubmitCommands() and a new flushIMpl is added to wrap around
most logic inside flush().
Bug: angleproject:372268711
Change-Id: I54eed8a81f4153d52ab962f213cacc87a73b89ac
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6037491
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
17904b43
|
2024-11-19T16:37:43
|
|
Vulkan: Restrict EGL_ANDROID_front_buffer_auto_refresh support
Original functionality supported scenario
where `VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR` and
`VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR` modes may be
incompatible, requiring a call to `deferAcquireNextImage()` method in
order to cause swapchain recreation without swap.
The `eglSurfaceAttrib()` may be called from any thread, this means that
`deferAcquireNextImage` may be also called from any thread - which is
not thread safe.
This CL restricts exposing the extension only when
VK_EXT_swapchain_maintenance1 extension is also supported, where
present modes expected to be compatible on Android, so no need for
swapchain recreation and therefore - `deferAcquireNextImage()` call.
Not requiring to call `deferAcquireNextImage()` improves thread safety
of `WindowSurfaceVk::setAutoRefreshEnabled()` method.
There is still race condition accessing `mDesiredSwapchainPresentMode`
but it will be addressed in a separate CL.
Bug: angleproject:42265697
Bug: angleproject:379762019
Change-Id: I4631c736188eb52a5476e1a2bed3439d49cf12d4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6035187
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
74f74b63
|
2024-11-14T10:07:34
|
|
Vulkan: Add ContextVk::onFramebufferBoundary() function
This makes a more formal API to track frame boundary. Also adds a
uint32_t mCurrentFrameCount to track the total number of frames rendered
so that we could use for heuristic purpose.
Bug: angleproject:372268711
Change-Id: I153497403ed0d8fde18f1786186ce600df60c514
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6022549
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
bf07bcb7
|
2024-11-11T17:23:43
|
|
Vulkan: Remove dead code since mSwapchainImages always valid
All elements of the `mSwapchainImages` always contain valid images.
This fact makes code calling `acquireNextSwapchainImage()` in the
`WindowSurfaceVk::lockSurface()` a dead code. Probably, instead of
`acquireNextSwapchainImage()` it should call
`doDeferredAcquireNextImage()` if `needsAcquireImageOrProcessResult()`
is true, but this is another issue. This CL simply removes a dead code.
Bug: angleproject:42264593
Bug: angleproject:42262606
Change-Id: Ic7bda330d74e1ccad149ffab723954f45dab700b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6018092
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
08c1724f
|
2024-10-11T14:29:00
|
|
Vulkan: Support GL_ARM_shader_framebuffer_fetch_depth_stencil
Bug: angleproject:352364582
Change-Id: I63fd78314fa7ebccbf366c252e309a9c0f09c8c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938150
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65fcf9c4
|
2024-10-26T10:53:18
|
|
Vulkan: Remove redundant dependent feature checks
Since [1], when a feature is overriden, the dependent features
automatically take the override into account. Tests no longer need to
account for dependent features, neither does the logic in the code.
[1]:https://chromium-review.googlesource.com/c/angle/angle/+/4749524
Bug: angleproject:42266725
Change-Id: I5440aba4a89cffbe710e26ad7de4cfee783e9bdf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5967414
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
1608d0be
|
2024-10-10T16:53:15
|
|
Vulkan: Isolate framebuffer fetch no-RP-break optim from DR
Prior to [1], changes to framebuffer fetch usage by shaders caused a
render pass break. This was due to a limitation of render pass
compatibility rules. It also caused other headache, such as needing to
clear the render pass cache, recreating pipelines etc.
[1]:https://chromium-review.googlesource.com/c/angle/angle/+/3697308
In [1] an important optimization was implemented for tiling GPUs where
ANGLE permanently switched to framebuffer fetch mode on first
encountering framebuffer fetch use. From that point on, ANGLE would
always make every render pass framebuffer fetch compatible.
In reality, the render pass break was unnecessary, which became apparent
with dynamic rendering (for example that whether the render pass
includes input attachments has no bearing on a pipeline that doesn't use
input attachments at all). In [2], dynamic rendering kept the render
pass break + permanent switch behavior for simplicity.
[2]:https://chromium-review.googlesource.com/c/angle/angle/+/5637155
This change untangles the optimization done for legacy render passes
from dynamic rendering, allowing dynamic rendering to start every render
pass without framebuffer fetch and enable it later if a framebuffer
fetch program is used.
This is in preparation for supporting depth/stencil framebuffer fetch,
where a perma-switch is troublesome (for example in combination with
read-only depth/stencil feedback loops).
Bug: angleproject:352364582
Change-Id: I31221cf22a28d58b9b2bf188e9c0b786cd0fe3d2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5923120
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
fdec6935
|
2024-09-20T16:29:03
|
|
Workaround supportsSurfaceMaintenance1 on Linux with llvmpipe
Presence of multiple ICD appears to confuse the loader and we end up
with support reported but vkGetPhysicalDeviceSurfaceCapabilities2KHR
not actually working (see bug for more detials)
Bug: angleproject:368647924
Change-Id: Idc813b99f873643d067cc4b4e38f1ed5249500b4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5875015
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
1b4d6185
|
2024-09-12T09:18:46
|
|
Vulkan: Cleanup sRGB related code
Image and image view code is littered with sRGB related enums, even
in places that don't deal with sRGB. Remove sRGB related parameters
from initLayerImageView and getLevelLayerDrawImageView methods, which
now assume default values. Add dedicated methods that allow overriding
sRGB state values.
Also introduce ColorspaceState struct that consolidates all sRGB
related states, this will be used in follow up changes to track
and infer colorspace of image views
Bug: angleproject:40644776
Change-Id: Ifb366db48043e376f9ff6c30c852c44dd96562a1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5860808
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
8c12874c
|
2024-09-12T11:26:29
|
|
vulkan: add double buffer swapchain for fifo mode.
Double buffer swapchain usually drop the performance.
But at B* the default fps cap for silver device still at 30fps.
This change is for reduce latency.
Bug: b/311022968
Change-Id: Ida4044f439bbe3f235d53f5d1d2f945533cbb094
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5858255
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
177d15b3
|
2024-08-23T19:34:34
|
|
Vulkan: Simplify WindowSurfaceVk::prepareSwap() method
In case of swapchain recreate inside `prepareSwap()`, perform unlocked
ANI call as usual. ANI processing will be done late in `swap()` or
`getBufferAge()`. This is possible, because surface `getWidth/Height()`
is no longer require valid `mColorRenderTarget`.
Because of the above, `swapchainRecreatedOut` parameter was removed.
Additionally, `getBufferAge()` now uses
`doDeferredAcquireNextImageWithUsableSwapchain()` in order to process
possible VK_ERROR_OUT_OF_DATE_KHR error and recreate the swapchain,
instead of failing.
Test: angle_end2end_tests --gtest-filter=EGLSingleBufferTest.AcquireImageFromSwapImpl*
Bug: angleproject:6851
Bug: angleproject:8133
Change-Id: Ieb375781da2b1108d0a5e11dbb012885a946688e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5806335
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
636d838e
|
2024-08-27T16:30:04
|
|
Vulkan: Decouple Window Surface width/height from color RT
`mColorRenderTarget` is invalidated in `releaseSwapchainImages()`
method, when swapchain is recreated. It remains invalid until ANI
result is processed in the `postProcessUnlockedTryAcquire()` method.
In case if swapchain recreate and processing of the results are done
in different API calls (prepareSwap and swap), other thread way query
invalid render target size using `eglQuerySurface()` API. Currently
this should not be possible, but may change in the future.
Another way to have invalid render target, is if ANI fails after
swapchain recreate.
To avoid above problems, surface size is cached after swapchain is
recreated. Implementation is moved to the `SurfaceVk` base class.
The `WindowSurfaceVk::getRotatedWidth/Height()` methods were unused.
`mColorRenderTarget` is now only acessed after ANI result is processed.
Bug: angleproject:1319
Change-Id: Ibc007f1e8d30b6281be93c4561e05dd2f14f44d3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5816834
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
74816e9e
|
2024-08-29T15:58:22
|
|
Vulkan: Cleanup RenderTargetVk release/destroy methods
Current implementation of `release()` and `destroy()` methods does not
actually invalidate state of the object. All they do is manage the
Framebuffer cache.
The `release()` method renamed to `releaseFramebuffers()` to match its
behavior.
Added new `releaseImageAndViews()` method that calls
`releaseFramebuffers()` and also null the pointers in order to catch
invalid usage in ASSSERTs (for example: usage of
`SurfaceVk::mColorRenderTarget` after swapchain recreation but before
ANI processing).
`destroy()` is updated to also call `reset()`.
`releaseFramebuffers()` is only used in `TextureVk` class. In case of
`releaseImageViews()`, arrays are cleared, so there is no point calling
`releaseImageAndViews()`. In case of `refreshImageViews()`, render
targets may be reused, since all pointers remain valid.
`RenderbufferVk` and `WindowSurfaceVk` are using new
`releaseImageAndViews()` and updated `destroy()` methods.
Other changes:
- Replace clearing of RT arrays in `TextureVk::setImageHelper()` with
ASSERTs.
- Fix ASSERT in `TextureVk::releaseImageViews()`, but it seems that this
code path is impossible.
Bug: b/234769934
Change-Id: I431d25b81dd4dd343149c12e680e5c997aa18436
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5822575
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
1db80b88
|
2024-07-10T12:47:42
|
|
Reland "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]"
This is a reland of commit c379ff48043a47e444c388c45270db40d3172d50
Original change's description:
> Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
>
> Bug: angleproject:42267038
> Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Charlie Lao <cclao@google.com>
Bug: angleproject:42267038
Change-Id: I083e6963b5421386695e49a9872edbb2016c9763
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691342
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
584fbcee
|
2024-07-10T12:43:34
|
|
Vulkan: Rework swap-time barrier logic
Avoids unnecessary transitions when overlay is enabled
Bug: angleproject:42267038
Change-Id: I0534911c0142c5e94cf3be112283fb98fcde0f6c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691346
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
373ac541
|
2024-07-10T11:14:47
|
|
Vulkan: Make surface RP check independent from framebuffer object
With dynamic rendering, there is no framebuffer object, so checking
whether the currently open render pass belongs to the window surface (at
swap time) is made independent from these objects.
Bug: angleproject:42267038
Change-Id: I408e2376ba865b64fa1e8890316e8f57c08c695f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691345
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7d461b21
|
2024-07-10T14:11:53
|
|
Revert "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]"
This reverts commit c379ff48043a47e444c388c45270db40d3172d50.
Reason for revert: Regresses CPU perf and memory when _not_ using DR
Original change's description:
> Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
>
> Bug: angleproject:42267038
> Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Charlie Lao <cclao@google.com>
Bug: angleproject:42267038
Change-Id: I3865f0d86813f0eeb9085a92875a33bd449b907f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691337
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6052d0f4
|
2024-07-03T15:17:23
|
|
Vulkan: Fix EGL_EXT_buffer_age with single buffered surface
The specification:
4) What is the buffer age of a single buffered surface?
RESOLVED: 0. This falls out implicitly from the buffer age
calculations, which dictate that a buffer's age starts at 0,
and is only incremented by frame boundaries. Since frame
boundary functions do not affect single buffered surfaces,
their age will always be 0.
Test: angle_end2end_tests --gtest_filter=EGLBufferAgeTest.SingleBuffer*
Bug: angleproject:3529
Change-Id: Iab5da26d1bce56d928398cc250d900465fc5d261
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5675986
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c379ff48
|
2024-06-10T22:01:57
|
|
Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
Bug: angleproject:42267038
Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
8c546d35
|
2024-06-25T12:49:40
|
|
Vulkan: Limit VkEvent for usage matters for Manhattan31 only
If we use VkEvent to track all image operations causes performance
regression on some app traces, including manhattan10 trace. This mainly
because of CPU overhead comes with VkCmdSetEvent, mostly inside vulkan
driver. These app traces likely not benefit from VkEvent because the
specific bubble (false dependency) does not manifest on these app
traces, but the CPU overhead takes a performance toll on it. In order to
strike a balance between benefit and overhead, this CL removes most of
VkEvent usage and only leaves the ones that matters for manhattan31. The
only we still keeps are generateMipmap, dispatchCompute, texture
sampling. We can always add more if more beneficial usage cases comes up
and no regression in other traces.
Bug: b/336844257
Change-Id: I346fe70bc33e57edf04e933a2db0f79738c4481d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5654737
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d193d51b
|
2024-06-17T22:46:08
|
|
Replace issue ids post migration to new issue tracker
This change replaces anglebug.com/NNNN links.
Bug: None
Change-Id: I8ac3aec8d2a8a844b3d7b99fc0a6b2be8da31761
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637912
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e29d643e
|
2024-05-07T13:40:18
|
|
Vulkan: Fix missing per-present-mode query
... if VK_EXT_surface_maintenance1 is supported but
VK_EXT_swapchain_maintenance1 isn't. The code mistakenly made the
appropriate query conditional to the presence of swapchain_maint1
instead of surface_maint1. On devices where surface_maint1 was
available but swapchain_maint1 wasn't, this caused a VVL error that is
now fixed.
Bug: angleproject:8680
Change-Id: Ide9a87f0e50887572f693d741d5476361320ea19
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5522756
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c3a1cae4
|
2024-04-15T14:58:55
|
|
Use angle::SimpleMutex everywhere in libGLESv2
Only cases left that use std::mutex are:
- Share group and the context ErrorSet mutexes as they need try_lock()
- Anywhere mutexes are used in conjunction with std::condition_variables
(as they explicitly require std::mutex)
Bug: angleproject:8667
Change-Id: Ib6d68938b0886f9e7c43e023162557990ecfb300
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5453294
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a96e9197
|
2024-04-25T10:35:02
|
|
Vulkan: Add RefCountedEvent class and VkCmdSetEvent call
This CL defines RefCountedEvent class that adds reference counting to
VkEvent. CommandBufferHelper and ImageHelper each holds one reference
count to the event. Every time an event is added to the command buffer,
the corresponding RefCountedEvent will be added to the garbage list
which tracks the GPU completion using ResourceUse. That event garbage's
reference count will not decremented until GPU is finished, thus ensures
we never destroy a VkEvent until GPU is completed.
For images used by RenderPassCommands, As
RenderPassCommandBufferHelper::imageRead and imageWrite get called, an
event with that layout gets created and added to the image. That event
is saved in RenderPassCommandBufferHelper::mRefCountedEvents and that
VkCmdSetEvents calls are issued from
RenderPassCommandBufferHelper::flushToPrimary(). For renderPass
attachments, the events are created and added to image when attachment
image gets finalized.
For images used in OutsideRenderPassCommands, The events are inserted as
needed as we generates commands that uses image. We do not wait until
commands gets flushed to issue VkCmdSetEvent calls. A convenient
function trackImageWithEvent() is added to create and setEvent and add
event to image all in one call. You can add this call after the image
operation whenever we think it benefits, which gives us better control.
(Note: Even if forgot to insert the trackImageWithEvent call, it is
still okay since every time barrier is inserted, the event gets
released. Next time when we inserts barrier again we will fallback to
pipelineBarrier since there is no event associated with it. But that is
next CL's content).
This CL only adds the VkCmdSetEvent call when feature flag is enabled.
The feature flag is still disabled and no VkCmdWaitEvent is used in this
CL (will be added in later CL).
Bug: b/336844257
Change-Id: Iae5c4d2553a80f0f74cd6065d72a9c592c79f075
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5490203
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
c74d2634
|
2024-04-19T12:19:51
|
|
Vulkan: Update mSurfaceCaps with per-present mode caps.
Vulkan spec says "The per-present mode image counts may be less-than or
greater-than the image counts returned when VkSurfacePresentModeEXT is
not provided". Riht now we are using the generic surfaceCaps information
which has smaller minImageCount. This triggers VVL error
VUID-VkSwapchainCreateInfoKHR-presentMode-02839.. This CL updates
mSurfaceCaps and mMinImageCount with per-present mode caps and create
swapChain with proper minImageCount.
Bug: angleproject:8672
Change-Id: I6061d2db8e98032dcb2c3225f2976013a99336a9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5467850
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
9475ac40
|
2023-11-15T10:25:06
|
|
Vulkan: Make efficient MSAA resolve possible
Prior to this change, using a resolve attachment to implement resolve
through glBlitFramebuffer was done by temporarily modifying the source
FramebufferVk's framebuffer description. This caused a good deal of
complexity; enough to require the render pass to be immediately closed
after this optimization.
The downsides to this are:
- Only one attachment can be efficiently resolved
- There is no chance for the MSAA attachment to be invalidated
In this change, resolve attachments that are added because of
glBlitFramebuffer are stored in the command buffer, with the
FramebufferVk completely oblivious to them. When the render pass is
closed, either the FramebufferVk's original framebuffer object is used
(if no resolve attachments are added) or a temporary one is created to
include those resolve attachments.
With the above method, the render pass is able to accumulate many
resolve attachments as well as have its MSAA attachments be invalidated
before it is flushed.
For a FramebufferVk that is resolved in this way, there used to be two
framebuffers created each time and thrown away as the code alternated
between starting a render pass without a resolve attachment and then
closing with one. With this change, there is now one framebuffer
(without resolve attachments) that is cached in FramebufferVk (and is
not recreated every time), and only the framebuffer with resolve
attachments is recreated every time.
Ultimatley, when VK_KHR_dynamic_rendering is implemented in ANGLE, there
would be no framebuffers to create and destroy, and this change paves
the way for that support too.
WindowSurfaceVk framebuffers are still imagefull. Making them imageless
adds unnecessary complication with no benefit.
-----------------
To achieve efficient MSAA rendering on tiling hardware, applications
should do the following:
```
glBindFramebuffer(GL_FRAMEBUFFER, msaaFBO);
// Clear the framebuffer to avoid a load
// Or invalidate, if not needed to load:
// glInvalidateFramebuffer(GL_DRAW_FRAMEBUFFER, ...);
glClear(...);
// Draw calls
// Resolve into the single sampled framebuffer
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, resolveFBO);
glBlitFramebuffer(...);
// Immediately discard the contents of the MSAA buffer, to avoid store
glInvalidateFramebuffer(GL_READ_FRAMEBUFFER, ...);
```
The above would translate to the following Vulkan render pass:
- MSAA LOAD_OP_CLEAR/DONT_CARE
- MSAA STORE_OP_DONT_CARE
- Resolve LOAD_OP_DONT_CARE
- Resolve STORE_OP_STORE
This makes sure the MSAA data doesn't leave the tile memory and greatly
reduces bandwidth usage.
Once anglebug.com/4892 is fixed, this would also allow the MSAA image
to never be allocated either.
Bug: angleproject:7551
Bug: angleproject:8625
Change-Id: Ia9f4d20863d76a013d8495033f95c7b39f77e062
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5388492
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
318e5e02
|
2024-03-24T08:17:56
|
|
Vulkan: Update EGL_EXT_buffer_age implementation
1. Buffer age is always 1 when swap behavior is EGL_BUFFER_PRESERVED.
2. WindowSurfaceVk::getBufferAge no longer acquires a swapchain image.
See commit: b46cf6989f6fe8db5f0759001f633681a96fadde
3. It is valid to pass attributes of eglQuerySurface API to
eglQuerySurface64KHR API
4. Add deadlock fix to eglQuerySurface64KHR
Bug: angleproject:3529
Bug: angleproject:6851
Tests: EGLLockSurface3Test.QuerySurfaceAndQuerySurface64Parity*
Tests: EGLBufferAgeTest.QueryBufferAge*
Change-Id: Idf3c4fc08364f671fb02e99111be2beb7a1d9f3d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5389461
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
e3aac00b
|
2024-03-18T18:18:36
|
|
Vulkan: only request OPAQUE compositeAlpha on Android if no alpha
Android used to only advertise INHERIT bit with the expectations that a
Vulkan swapchain is only connected with SurfaceFlinger so that WM takes
full control of the composition. That works fine till an encoder surface
with EGL client (via ANGLE + KHR_swapchain) hits a suboptimal code path
if the backing storage is RGBA but not RGBX. This change prepares for
Android KHR_swapchain advertising OPAQUE bit for such surfaces as a hint
to get RGBX backing.
Bug: b/328125698, b/328122401
Test: encoder cts is passing, and no regression to ImageReader use cases
Change-Id: Ia7f1c69935690f20efac6295eb824bee0d03eb07
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5378134
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
914fe61b
|
2024-03-15T13:20:49
|
|
Vulkan: Rename RendererVk.* to vk_renderer.*
Done in a separate CL from the move to namespace vk to avoid possible
rebase-time confusion with the file name change.
Bug: angleproject:8564
Change-Id: Ibab79029834b88514d4466a7a4c076b1352bc450
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5370107
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
60aaf4a0
|
2024-03-14T12:58:56
|
|
Vulkan: Move renderer to namespace vk
This class is agnostic of EGL. This change moves it to namespace vk for
use with the OpenCL implementation
Bug: angleproject:8564
Change-Id: I57f7807d6af8b3d5d7f8efbaf8b5d537a930f881
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5371324
Reviewed-by: Austin Annestrand <a.annestrand@samsung.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
aba3705b
|
2024-03-02T21:58:34
|
|
Vulkan: Completely remove egl::Display from RendererVk
This class is now independent of EGL. The only mentions of EGL is
egl::ContextPriority, which is just an enum and is tolerable for now.
OpenCL can now instantiate RendererVk without having to create a temp
egl::Display.
Bug: angleproject:8564
Change-Id: Ia78cfcb3a48c97f397441cf7cda71d74cfaddd8f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5335581
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
545e3f6e
|
2024-03-01T23:27:03
|
|
Vulkan: Decouple RendererVk from egl::BlobCache
The new vk::GlobalOps class abstracts access to egl::BlobCache. This is
a step towards decoupling RendererVk from egl::Display for direct use
with OpenCL.
Bug: angleproject:8564
Change-Id: I7b3910254430df74b889759639da1749735584a7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5332082
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
6367f541
|
2024-01-25T10:16:04
|
|
Vulkan: supply YcbcrConversionDesc earlier
Previously, the AHB import path would allow ImageHelper to build a bogus
YcbcrConversionDesc (in initExternal) and then later overwrite it with
what it wanted. The intermediate state was not necessarily valid, and
could cause assertion failures and VVL errors.
Instead, have ImageHelper clients provide the conversion they want
upfront. In the non-external case, build an appropriate conversion
for formats which need them, before delegating to initExternal.
Bug: b/315387961
Change-Id: Icc8f561bb2de0289ceec56d41978b8c4651a47a2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5232769
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
341906d5
|
2024-01-22T10:19:25
|
|
Vulkan: Never delay device and queue selection
Previously, when multiple queue families where eligible, ANGLE delayed
the decision on which queue family to use and delayed device creation
until a window surface was created.
This assumption was never correct. The application may start rendering
to pbuffers or using EGL_KHR_surfaceless_context long before it creates
a window surface. So a queue may need to be chosen regardless of its
surface present capabilities. Once done, ANGLE has no mechanism to
change that queue should a window surface require a different queue.
This change drops the pretense to support multiple queue families
properly and makes ANGLE always choose the first graphics queue family
it encounters. So far, only MoltenVk seems to expose multiple graphics
queue families, and choosing the first one ultimately correct for the
purposes of presenting to a MacOS surface.
Bug: angleproject:8478
Change-Id: I8efbfe0c8036be5f9cee01eb657f83f85a4864fd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5225081
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b46cf698
|
2023-11-30T11:00:18
|
|
Vulkan: Fix Android deadlock with querying buffer age
Similar to eglSwapBuffers, eglQuerySurface with EGL_BUFFER_AGE_EXT can
cause a call to vkAcquireNextImageKHR.
Bug: angleproject:6851
Bug: b/313975825
Change-Id: If3f0521219cab9aba2aeb2b70958bf0f197bc96a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5077406
Reviewed-by: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f7eb7efb
|
2023-11-28T11:20:57
|
|
Vulkan: Fix camera panorama hang
When EGL attributes does not speficy color space, right now we pick
VK_COLOR_SPACE_SRGB_NONLINEAR_KHR. This overwrites the color space
people set via ANativeWindow. This causes camera goes into CSC
conversion and errors out and stops media codec pipeline and causes
camera to hang. This CL enables mapUnspecifiedColorSpaceToPassThrough
feature flag for all platform that supports VK_EXT_swapchain_colorspace
so that it will pick VK_COLOR_SPACE_PASS_THROUGH_EXT and vulkan
swapchain code will try to keep whatever color space surface already
has. The feature flag is still kept here in case there is regression and
we need to experiment this feature flag again. We can remove it once
everything settles down.
This CL also adds updateColorSpace() and getActualFormatID() to
de-duplicate the logic of R8G8B8_UNORM overriding and use of
VK_COLOR_SPACE_PASS_THROUGH_EXT.
Bug: b/309480316
Bug: b/302196568
Change-Id: I0952fe78c2bfd59446391c553745b2b5cb152a9d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5066801
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
c5eb810b
|
2023-11-14T15:01:25
|
|
Remove angle::Result::Incomplete entirely
Bug: angleproject:8414
Change-Id: I8d607614614360b65c530e3e7647d8a7ba38b18e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5031191
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
e7418836
|
2023-08-16T14:25:52
|
|
Vulkan: Add context flushing as OOM fallback
* As a new fallback for out-of-memory errors, if an allocation results
in device OOM, the context is flushed and the allocation is retried.
* Functions related to buffer/image allocations now return a VkResult
value instead of angle::Result, which will be bubbled up to a higher
level for safer handling.
* The OOM is no longer handled at the level where the allocation
happens, but is moved up to the context.
* Added two functions to ContextVk for allocating memory for images and
buffer suballocations, which also include the fallback options.
* initBufferAllocation(): Uses BufferHelper::initSuballocation()
* initImageAllocation(): Uses ImageHelper::initMemory()
* Moved initNonZeroMemory() out of the following functions:
* BufferHelper::initSuballocation()
* Moved to ContextVk::initBufferAllocation().
* ImageHelper::initMemory()
* Moved to ContextVk::initImageAllocation().
* Also moved to new function:
ImageHelper::initMemoryAndNonZeroFillIfNeeded().
This function replaced the rest of initMemory() usages outside
initImageAllocation().
* New macros for memory allocation
* VK_RESULT_TRY()
* If the output of the command inside it is not VK_SUCCESS, it will
return with the error result from the command.
* VK_RESULT_CHECK()
* If the output of the command inside it is not VK_SUCCESS, it will
return with the input error.
* Added a test in which allocation would fail due to too much pending
garbage without the fix on some platforms. The test ends once there
has been a submission.
* New suite: UniformBufferMemoryTest
* Added a similar test for flushing texture-related pending garbage.
* New suite: Texture2DMemoryTestES3
Bug: b/280304441
Change-Id: I60248ce39eae80b5a8ffe4723d8a1c5641087f23
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4787949
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9740b01b
|
2023-09-08T16:30:08
|
|
Enhance UnlockedTailCall run method
UnlockedTailCall::CallType is now std::function<void(void *)>
This is in preparation for upcoming changes where unlocked
tail calls need access to objects outside block and namespace
scope.
Bug: angleproject:8340
Tests: UnlockedTailCall*
Change-Id: Ida6822b701c5c11ce4b8f6e3aae53108755e2cad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4852021
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
00daa451
|
2023-08-28T16:30:23
|
|
Vulkan: Include minImageCount in swapchain check
The following VVL error has been firing for traces run in
landscape mode:
[ VUID-VkSwapchainCreateInfoKHR-presentMode-02839 ]
vkCreateSwapchainKHR(): pCreateInfo.minImageCount 4, which is outside
the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR()
(i.e. minImageCount = 5, maxImageCount = 64).
On Android, rotation can cause minImageCount to change.
We need to detect this as an out of date swapchain.
Test: angle_trace_test --gtest_filter=TraceTest.among_us
Bug: b/289274676
Change-Id: Ie75adec5f5318b73c0c27efc134f10f53485692d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4819790
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
0d67d1bb
|
2023-08-29T11:19:35
|
|
Vulkan: Support EGL_EXT_gl_colorspace_bt2020
Add support for following 3 BT2020 colorspace extensions
1. EGL_EXT_gl_colorspace_bt2020_hlg
2. EGL_EXT_gl_colorspace_bt2020_linear
3. EGL_EXT_gl_colorspace_bt2020_pq
Bug: angleproject:8330
Tests: EGLSurfaceTest.CreateWithEGLConfig1010102Support*
Change-Id: I3a6ca0daa9ad4400da3834f43678b0db816ba6e4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4824045
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
8138ae9b
|
2023-07-07T14:16:07
|
|
Vulkan: EGL's DISPLAY_P3_PASSTHROUGH -> VK's DISPLAY_P3_NONLINEAR
From
https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_gl_colorspace_display_p3_passthrough.txt
If its value is EGL_GL_COLORSPACE_DISPLAY_P3_PASSTHROUGH_EXT, then a
non-linear, sRGB encoded Display-P3 color space is assumed
Bug: b/289125521
Test: cvd start
Test: cts -m CtsViewTestCases
-t android.view.cts.TextureViewTest#testGetBitmap_8888_PassthroughP3
Change-Id: I07c77c86bbc0d82923ad7435cd2a5558770cd2e3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4673910
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
|
|
|
6eea5ff4
|
2023-07-18T12:52:37
|
|
Vulkan: fix default MSAA framebuffer clear issue.
Bug: b/290813597
Change-Id: I134c5a99382ca30dbd885a17dfa3c7ac227480ff
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4698113
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Hailin Zhang <hailinzhang@google.com>
|
|
ac263582
|
2023-06-19T12:26:44
|
|
Vulkan: add workaround for VK_EXT_full_screen_exclusive on AMD
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>
|
|
|
86e21fa2
|
2023-06-12T13:36:21
|
|
Vulkan: Refactor angle::Format depth/stencil checks
Bug: b/246008627
Change-Id: If0a2992c5bd66adf27c6866aea04e54ba465a522
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4608489
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
dbffa5d3
|
2023-05-30T15:43:45
|
|
Vulkan: Update present history logic
Keeping old Swapchain's `ImagePresentOperation`s with Fences can lead to
multiple "old swapchains" lists. This may cause situations exceeding
the `kMaxOldSwapchains` limit.
Instead of marking `ImagePresentOperation` as corresponding to an older
swapchain, accumulate all present history in the `mOldSwapchains`.
Since Fences are only used when VK_EXT_swapchain_maintenance1 is
supported, instead of attaching "old swapchains" to the first present
operation, they are destroyed when present Fences are signaled in the
new `cleanUpOldSwapchains()` method.
Also this CL fixes a bug:
if (mPresentHistory.empty() || mPresentHistory.back().imageIndex == kInvalidImageIndex)
The above condition will always pass when VK_EXT_swapchain_maintenance1
is supported.
Bug: angleproject:7847
Change-Id: I1a41944456756b8af740f1903c873823323a2e0b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4505952
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
95f57b19
|
2023-01-17T19:24:04
|
|
Vulkan: Fix Shared Present Mode "acquireNextSwapchainImage()"
- no need to call "vkAcquireNextImageKHR()" in
Shared Present Mode.
- proper VkResult processing (VK_SUBOPTIMAL_KHR replaced
with VK_SUCCESS).
Bug: angleproject:6878
Change-Id: Ib20ae1f5de3a3cc13bfc4ef034076e3402f93d31
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4489464
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
552e7468
|
2023-05-26T18:39:55
|
|
Vulkan: Do not use ANI Fence in present semaphore recycling
Fences from `vkAcquireNextImageKHR()` has many problems on some
Intel drivers, and one of them does not have a workaround. Instead of
using ANI Fence, this change will use `swapSerial`, that has execution
dependency on ANI semaphore. As result, semaphore recycling will be
delayed a little longer, until the Device finises rendering to the
image. On practice, this will not significantly affect the total number
of allocated semaphores.
As a bonus, this change also fixes a bug with Shared Present Mode:
Current logic assumes that PE will only signal image's ANI fence after
waiting on previous present semaphore with this image. In reality, PE
returns same image index and fence that is always signaled.
Additionally, ANI call is not required at all.
There is no 100% safe solution when not using:
VkSwapchainPresentFenceInfoEXT
This CL will recycle present semaphores only after next present
semaphore is signaled. This not only ensures, that present semaphores
are not reused inflight, but also gives time to PE to finish waiting on
the semaphore until next present.
Bug: angleproject:8155
Bug: angleproject:7847
Change-Id: Ia112190d77ea7e04f8f9755cf56f5387744dc599
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4572426
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
53b2db67
|
2023-05-26T13:34:39
|
|
Vulkan: Reset Swapchain Fence before recycling
Depending on the Intel GPU hardware and driver version, crash may
happen when accessing ANI Fence after Swapchain destruction.
This access includes call to: `vkGetFenceStatus()`, `vkWaitForFences()`,
`vkResetFences()`, and `vkDestroyFence()`.
Resetting Fence before recycling will "detach" it from the Swapchain,
allowing safe usage/destruction of the Fence after that Swapchain
destruction.
For other devices and drivers, this change is harmless. Only difference
is that there will be extra reset calls for items that were recycled but
never used before (number of such cases extremely low, compared to
cases when Fences are reused).
Additionally, this change adds `ASSERT(garbageObject.valid())` into the
`Recycler<>`. Before this change, it was possible to recycle invalid
fence in the `ImagePresentOperation::destroy()` method. Luckily, this
happened only in `WindowSurfaceVk::destroy()`, where invalid recycled
fence is not used (it is safe to destroy invalid fence).
Bug: angleproject:8155
Change-Id: I0adbaf63333536523004a077977eb68cfaccd6f7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4572425
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
bcccb6c4
|
2023-05-30T18:21:06
|
|
Vulkan: Minor fix in doDeferredAcquireNextImage() method
If call `doDeferredAcquireNextImage()` after `prepareSwap()`, the
`prepareForAcquireNextSwapchainImage()` method will be called again,
and may possible recreate the Swapchain while there is ANI result that
needs processing.
In the current code the above is not possible (except if call
`prepareSwap` directly from the application side). This may be possible
in the future, when ANI is deferred until RenderPass end, that may
happen in the `flushImpl()` of the `swapImpl()`.
This change skips `prepareForAcquireNextSwapchainImage()` if there is
ANI result that needs processing. Additionally,
`doDeferredAcquireNextImageWithUsableSwapchain()` call in `swapImpl()`
replaced with `doDeferredAcquireNextImage()` for simplicity.
Possible call sequences after this change:
prepareSwap:
prepareForAcquireNextSwapchainImage()
doDeferredAcquireNextImageWithUsableSwapchain()
or
prepareSwap:
prepareForAcquireNextSwapchainImage()
TryAcquireNextImageUnlocked()
other API:
doDeferredAcquireNextImage():
// skipped - prepareForAcquireNextSwapchainImage()
doDeferredAcquireNextImageWithUsableSwapchain()
or
other API:
doDeferredAcquireNextImage():
prepareForAcquireNextSwapchainImage()
doDeferredAcquireNextImageWithUsableSwapchain()
Bug: angleproject:6851
Bug: angleproject:8133
Change-Id: I4f973c05821fc9e43769cc2621f4467790118f23
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4572424
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
7b07818e
|
2023-05-29T19:46:40
|
|
Vulkan: Call resetAcquireNextImageSemaphore() only when required
Currently resetAcquireNextImageSemaphore() is called for each swapchain
image when swapchain is recreated and when EGLSurface is destroyed.
Releasing semaphores in case of swapchain recreation is not necessary,
since swapchain should not be recreated while there still image that
needs presenting. Call removed to reveal possible bugs, when recreate
happens without such present.
In case of EGLSurface destruction there may be only one image that has
semaphore. Call moved from `destroySwapChainImages()` to `destroy()`.
Bug: b/275624771
Change-Id: Ia4ce678f2b73785818150dfb276b19a5f5b7d25f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4567550
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
da41e7d9
|
2023-05-29T19:17:48
|
|
Vulkan: Account for queueSubmitOneOff() in SurfaceVk::mUse
There is a possibility to destroy EGLSurface without waiting for
`queueSubmitOneOff()` submission. One possible way to reproduce the
problem is to query `EGL_BUFFER_AGE_EXT` without any rendering in the
EGL_SINGLE_BUFFER mode.
This is a regression from:
Reland "Vulkan: SurfaceVk should only wait for GPU work that uses it"
https://chromium-review.googlesource.com/c/angle/angle/+/4406891
Test: angle_end2end_tests --gtest_filter=EGLSingleBufferTest.WaitOneOffSubmission*
Bug: b/267806287
Change-Id: I9478fcc4fd64b38747cbd80dea51137da9ef5f21
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4567549
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e24f4519
|
2023-01-19T02:30:39
|
|
Vulkan: Add externalFence into submitCommands()
Currently one-off fence in the `queueSubmitOneOff()` is used only in
`SyncHelperNativeFence::initializeWithFd()` to submit external fence.
Other `queueSubmitOneOff()` calls may use `QueueSerial` instead of a
fence.
Providing `fence` into `queueSubmitOneOff()` prevents tracking that
submission with `QueueSerial`. Therefore using `mUse` to collecting
`mFenceWithFd` as garbage will not work as intended.
This CL removes `fence` from `queueSubmitOneOff()` and adds
optional `externalFence` into `submitCommands()` instead.
Providing `externalFence` will cause additional `vkQueueSubmit()` call:
- first submission will submit everything as usual except using
the `externalFence`.
- second, will only submit internal `CommandQueue` fence for
`QueueSerial` tracking.
As the result of this CL, call to `initializeWithFd()` will always
produce two (2) `vkQueueSubmit()` calls. Previously it may be one (1) or
two (2) submissions. Future CL will reduce submission count to one (1).
If add additional submission into `queueSubmitOneOff()` instead of
`submitCommands()`, then maximum number of submissions will be
three (3).
Bug: angleproject:8117
Change-Id: I6f1ec12682aaab71bfc871e665fec2659df96b26
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392877
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
7fd01d03
|
2023-04-19T00:54:24
|
|
Vulkan: Throttle the CPU without holding the global lock
CPU throttling goes through CommandQueue and is thread-safe. Performing
it in an unlocked tail call allows other unrelated EGL calls to go
through.
Bug: angleproject:8135
Change-Id: Idb3841be5d8ea8c4b76217f6707be26b28ea39c2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4444027
Reviewed-by: Igor Nazarov <i.nazarov@samsung.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
d6481cdf
|
2023-04-18T22:36:39
|
|
Vulkan: Make eglPrepareSwapBuffersANGLE thread-safe
This function now only calls vkAcquireNextImageKHR without any further
processing of its results. That is deferred to the following
eglSwapBuffers call which does that under the share group lock.
The vkAcquireNextImageKHR call, together with the allocation of its
related semaphore and fence are protected by a fine-grained lock.
mNeedToAcquireNextSwapchainImage is turned atomic to guard against races
to call vkAcquireNextImageKHR from multiple contexts. Note that the
latter is not currently possible, but will be once calling
vkAcquireNextImageKHR is moved to the end of the render pass.
Bug: angleproject:6851
Bug: angleproject:8133
Change-Id: If2eeab475b4acf0621fd930c43d9d86a78a9197b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4445495
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Igor Nazarov <i.nazarov@samsung.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
aa1dc5da
|
2023-05-03T19:36:04
|
|
Revert "Vulkan: Simplify present history logic"
This reverts commit 1dee7cad284dda0c7c3ca18c10d8b7764353c7b0.
Reason for revert:
error: SurfaceVk.cpp:784 (destroy): ! Assert failed in destroy (..\..\src\libANGLE\renderer\vulkan\SurfaceVk.cpp:784): fence.getStatus(device) == VK_SUCCESS
Example builds:
https://ci.chromium.org/ui/p/angle/builders/try/win-test/13341/overview
https://ci.chromium.org/ui/p/angle/builders/try/win-test/13345/overview
Original change's description:
> Vulkan: Simplify present history logic
>
> Instead of marking `ImagePresentOperation` as corresponding to an older
> swapchain, accumulate all present history in the `mOldSwapchains`.
>
> Keeping old Swapchain's `ImagePresentOperation` with Fences can lead to
> multiple "old swapchains" lists. This may cause situations exceeding
> the `kMaxOldSwapchains` limit.
>
> Keeping items with Fences may help cleanup resources faster, but I think
> that it is not worth the code complexity. It also should be safe to
> recycle Fences at the same time as the Semaphores (when the first image
> is recycled).
>
> Also this CL may fix bug:
> if (mPresentHistory.empty() || mPresentHistory.back().imageIndex == kInvalidImageIndex)
> The above condition will always pass when using actual present Fences
> (VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_FENCE_INFO_EXT).
>
> Bug: angleproject:7847
> Change-Id: I39d854b03733dcb976c6bd7eb5f848d0cbece5d6
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4481251
> Reviewed-by: Charlie Lao <cclao@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Bug: angleproject:7847
Change-Id: Icf0cf5b12dd1efa682abebd83699b8d87dc07427
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4502778
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1dee7cad
|
2023-01-17T18:01:49
|
|
Vulkan: Simplify present history logic
Instead of marking `ImagePresentOperation` as corresponding to an older
swapchain, accumulate all present history in the `mOldSwapchains`.
Keeping old Swapchain's `ImagePresentOperation` with Fences can lead to
multiple "old swapchains" lists. This may cause situations exceeding
the `kMaxOldSwapchains` limit.
Keeping items with Fences may help cleanup resources faster, but I think
that it is not worth the code complexity. It also should be safe to
recycle Fences at the same time as the Semaphores (when the first image
is recycled).
Also this CL may fix bug:
if (mPresentHistory.empty() || mPresentHistory.back().imageIndex == kInvalidImageIndex)
The above condition will always pass when using actual present Fences
(VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_FENCE_INFO_EXT).
Bug: angleproject:7847
Change-Id: I39d854b03733dcb976c6bd7eb5f848d0cbece5d6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4481251
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
5c04f18a
|
2023-04-24T16:18:24
|
|
Vulkan: Remove DisplayVk param from ToEGL
It's no longer used
Bug: angleproject:3041
Change-Id: I5063152d1598aa5d40d94bbf5c643a1288589037
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4470387
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
cd6a58f2
|
2023-04-18T12:45:10
|
|
Vulkan: Make eglPrepareSwapBuffersANGLE less special
This function now uses the UnlockedTailCall mechanism so it doesn't
require as much special-case code generation.
This change does not fix the bug that this function is doing too much
work without holding any locks. That will be done in a follow up.
Bug: angleproject:6851
Bug: angleproject:8133
Change-Id: I77f4d514ff4aeef85bc1cc59214f7caa23aca7df
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4443186
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1328f2f3
|
2023-04-17T16:43:12
|
|
Vulkan: Destroy the surface without holding the EGL lock
This change defers surface destruction to the end of the entry point
that causes it so that it is done without holding the EGL lock. This
works around a specific deadlock in Android. On this platform:
- For EGL applications, parts of surface creation and destruction are
handled by the platform, and parts of it are done by the native EGL
driver. Namely, on surface destruction, native_window_api_disconnect
is called outside the EGL driver.
- For Vulkan applications, vkDestroySurfaceKHR takes full responsibility
for destroying the surface, including calling
native_window_api_disconnect.
Unfortunately, native_window_api_disconnect may use EGL sync objects and
can lead to calling into the EGL driver. For ANGLE, this is
particularly problematic because it is simultaneously a Vulkan
application and the EGL driver, causing `vkDestroySurfaceKHR` to call
back into ANGLE and attempt to reacquire the EGL lock.
Since there are no users of the surface when calling
vkDestroySurfaceKHR, it is safe for ANGLE to destroy it without holding
the EGL lock.
Note that only eglDestroySurface and eglMakeCurrent may lead to the
destruction of a window surface.
Bug: b/275176234
Bug: angleproject:8127
Change-Id: I02dc52e53e150943457e3f503e7ef30469f96b05
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4428754
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b875f47b
|
2023-04-24T11:11:03
|
|
Vulkan: Make mLastSubmittedQueueSerial reflect what it means
Right now we always update ContextVk::mLastSubmittedQueueSerial and
ContextVk::mLastFlushedQueueSerial when context becomes current, even
though it does not make any submission. It was done it this way mainly
for simplification (i.e, you will always see both queueSerial's index
the same). But this also causes a performance cost when a
mLastSubmittedQueueSerial is used to tag a resource. For example, if you
insert a EGLSync right after makeCurrent, that EGLSync may get a queue
serial number bigger than it should be, which will translate to longer
sync wait time. This CL changes these two queue serial to exact what the
name suggests, that it will only update if we made a "flush" or "submit"
call.
Bug: b/277644512
Change-Id: Ibe4c78985a3fe0726836d620202e5276894a8e7c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4458532
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
663b60b5
|
2023-04-12T09:51:32
|
|
Vulkan: More consistent fix for single buffer ANI semaphore wait
Transition into single buffer mode are generating two ANI calls. This CL
slightly improves the previous CL (crrev.com/c/4400011)'s handling of
ANI semaphore wait for single buffer mode. Instead of catching
outstanding ANI semaphore at present time, this CL consumes the
semaphore immediately just like layout change
Bug: b/275624771
Change-Id: I5418ec47b6bfc77af411c9205e1ae27adeb27976
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4419126
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
9ae918cb
|
2023-02-03T15:14:00
|
|
Reland "Vulkan: SurfaceVk should only wait for GPU work that uses it"
This is a reland of commit 5b63e1dc1d5e96018d0ad30582265a612d309f3b
The added fix is add contextVk::mLastSubmitQueueSerial into
Surface::mUse before calling finish.
Original change's description:
> Vulkan: SurfaceVk should only wait for GPU work that uses it
>
> Right now when we destroy swapchain, we call mRenderer->finish() to
> finish everything, even though the work is unrelated to this surface.
> This CL changes it to only wait for ResourceUse of all images in the
> swapChain.
>
> Bug: b/267806287
> Change-Id: I33d136ad50961fbf5fbb200ff0f89f1dbf23585d
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4220723
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/267806287
Change-Id: I160fd22595fcf292cc53c055e0678befa3b8501b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4406891
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d58fbf04
|
2023-04-05T12:32:09
|
|
Vulkan: Wait for surface ANI semaphore only if image is used
Right now there is a bug that surface's ANI semaphore is added to
context when WindowSurfaceVk::getAttachmentRenderTarget get called,
which gets called from FramebufferVk::syncState, which is before we end
the previous render pass, due to the endRenderpass usually is deferred
until next renderPass starts. This caused ANI semaphore gets added to
the previous render pass's submission, which does not use surface, and
thus a bubble in GPU execution pipeline where the user FBO rendering
gets unnecessarily blocked until ANI semaphore is signaled. This lowers
GPU utilization and thus GPU frequency gets dropped and frame time
increased. This CL stores ANI semaphore to ImageHelper object and when
barrier is generated, the ANI semaphore is moved to CommandBuffer. When
CommandBuffer gets flushed and submitted, it gets added to the
waitSemaphores vector and submitted to vulkan. Since all use of swap
chain image must go through barrier code first (you need at least change
layout), this ensures ANI semaphore gets waited in exact and robust way.
Only the submission that references the swap chain image will be waited.
With this CL, professional_baseball_spirits reduces frame time from 3.8
ms to 2.7 ms, achieving parity with native GLES on pixel 7 pro.
Bug: b/275624771
Change-Id: Ifa6cacf9e3bc147bfde54eb7def2fca48c50aca0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400011
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65ed3050
|
2023-04-04T11:57:38
|
|
Vulkan: Let recordWriteBarrier use CommandBufferHelper
This is preparation for next CL. It changes
OutsideRenderPassCommandBuffer argument to
OutsideRenderPassCommandBufferHelper for recordWriteBarrier() and
recordReadBarrier() calls, so that it has access to the helper object
(will be used in next CL). It passes CommandsState to executeBarriers()
instead of PrimaryCommandBuffer. No actual functionality change is
expected.
Bug: b/275624771
Change-Id: Ia06a0398a127539b0b642005803a498cb2a9d7f1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400407
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
233c128b
|
2023-01-17T19:21:58
|
|
Vulkan: Fix UBs when deleted attachment is used in a RenderPass.
Problem:
- "RenderbufferVk"/"TextureVk" with "mOwnsImage == false" used as
RenderPass attachment.
- "RenderbufferVk"/"TextureVk" deleted.
- Owning resource is destroyed ("EGLImage" and all siblings /
"EGLSurface").
- Crash (UB) may happen when ending RenderPass, flushing or executing
commands.
Fix adds tracking of "vk::ImageSourceID" value in
"vk::RenderPassAttachment" - IDs of objects, that originally provide
"vk::ImageHelper" images. This is necessary, because when using
EGLImage, there may be multiple "TextureVk" objects with same
"vk::ImageHelper", and need to call "finalizeImageLayout()" for the
correct attachment.
Bug: angleproject:8032
Test: angle_end2end_tests --gtest_filter=ImageTest*DeletedWhileInUse*
Test: angle_end2end_tests --gtest_filter=PbufferTest.UseAsFramebufferColorThenDestroy*
Change-Id: I50fdd9d6b6a9677adad2262373303b46de1dee4c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4296014
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
7ee61366
|
2023-03-09T16:18:56
|
|
Revert "Vulkan: SurfaceVk should only wait for GPU work that uses it"
This reverts commit 5b63e1dc1d5e96018d0ad30582265a612d309f3b.
Reason for revert: angle_deqp_internal_main_presubmit device lost in android rolls https://anglebug.com/8073
Original change's description:
> Vulkan: SurfaceVk should only wait for GPU work that uses it
>
> Right now when we destroy swapchain, we call mRenderer->finish() to
> finish everything, even though the work is unrelated to this surface.
> This CL changes it to only wait for ResourceUse of all images in the
> swapChain.
>
> Bug: b/267806287
> Change-Id: I33d136ad50961fbf5fbb200ff0f89f1dbf23585d
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4220723
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/267806287
Bug: angleproject:8073
Change-Id: Id0bfe7be670b7d44ed91e61f2c98a189bd1f214c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4324718
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
ad7949c6
|
2023-01-17T19:24:59
|
|
Vulkan: Remove "rx::vk::ImageHelper" move constructor.
Move constructor was only used in the "rx::SwapchainImage" structure.
This CL replaces "image" member with "std::unique_ptr<vk::ImageHelper>".
This will remove source of bugs.
Bug: angleproject:8052
Change-Id: Ic16f674095233baaa56fbe8a8fb7ef3e323a7331
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4294905
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
5b63e1dc
|
2023-02-03T15:14:00
|
|
Vulkan: SurfaceVk should only wait for GPU work that uses it
Right now when we destroy swapchain, we call mRenderer->finish() to
finish everything, even though the work is unrelated to this surface.
This CL changes it to only wait for ResourceUse of all images in the
swapChain.
Bug: b/267806287
Change-Id: I33d136ad50961fbf5fbb200ff0f89f1dbf23585d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4220723
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
1365f5b3
|
2022-09-09T17:19:26
|
|
Vulkan: Fix Swapchain Acquire Image Semaphore wait stage flags.
There is a screen tearing on G996B with single
"glClear(GL_COLOR_BUFFER_BIT)" no scissor in the frame.
Fixed by defining "kSwapchainAcquireImageWaitStageFlags" and
adding "VK_PIPELINE_STAGE_TRANSFER_BIT" stage flag.
Also added "VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT" stage, because first
use of the Swapchain Image after Acquire may be in the
"glBlitFramebuffer()" command.
This fix may slightly affect performance. In such case, a better fix
should be implemented (include only stages based on the actual first
use). However, this may be not trivial.
Additionally, "kSwapchainAcquireImageWaitStageFlags" is used as a source
stage mask in the "ImageLayout::Present" pipeline barrier. This is
needed in order to build a dependency chain from the Acquire Image
Semaphore to the layout transition's first synchronization scope, so
that layout transition happens after acquire semaphore is signaled.
Reference:
https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples#combined-graphicspresent-queue
https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rendering_and_presentation
Alternative fix of both issues is to define:
kSwapchainAcquireImageWaitStageFlags = VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT
This might potentially delay command buffer execution relative to the
Swapchain Acquire Image Semaphore signal operations, but will relax
the pipeline barrier.
Bug: angleproject:8030
Test: angle_end2end_tests --gtest_also_run_disabled_tests --gtest_filter=EGLSurfaceTest.DISABLED_RandomClearTearing*
Change-Id: I29f58862c4b369524b2555dd944e2fb67eebe956
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4271377
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
31684d8c
|
2023-02-18T11:11:57
|
|
Vulkan: Lazily create swapchain image views
In compliance with
VK_SWAPCHAIN_CREATE_DEFERRED_MEMORY_ALLOCATION_BIT_EXT.
Bug: angleproject:7878
Big: b/269606195
Change-Id: I917c6888b325f768dbc6384828a6e462792d3c0b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4267510
Reviewed-by: Ian Elliott <ianelliott@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
|
|
|
e1dfc00a
|
2023-02-15T16:21:37
|
|
Vulkan: Make waitForPendingPresent drain work in the calling thread
Since we are waiting, there is no point to have work done in
CommandProcessor's worker thread. It can just wait and drain the task in
the calling thread. This is consistent with
waitForResourceUseToBeSubmitted. This allows us to remove mutex and
condition variable from SwapchainStatus.
Bug: b/269524271
Change-Id: I9d7e17c77c879b6957fc3b74aab02f7f5c9db052
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4257252
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
79bfee1c
|
2023-02-15T15:33:56
|
|
Vulkan: Clean up CommandProcessor::queuePresent
Right now queuePresent API returns VkResult in two places, via return
value and SwapchainStatus structure. This CL makes it only return via
SwapchainStatus::lastPresentResult so that two code path are the same.
Bug: b/269524271
Change-Id: I7ab3c2bee08961a10718a2e5daa1c7f03e97e85d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4257927
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
a6dba4b4
|
2023-01-17T19:24:18
|
|
Vulkan: Minor fix in "WindowSurfaceVk::hasStagedUpdates()".
This CL adds check to prevent checking buffer that is not technically
acquired.
Also if in the future this function will be called for double buffered
surfaces it will not check a previous buffer.
Bug: b/237449314
Change-Id: I79f1a2c4cd05a5424e963503891449f310177e93
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4262070
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ceb49b1c
|
2023-01-17T19:21:43
|
|
Vulkan: Fix crashes when Surface is not current.
It is possible to destroy Surface while some resources are still
in use (by CPU/GPU):
1. Make Surface current.
2. Draw something.
3. Make other Surface current (same Context).
4. (optional - if test Surface is Window Surface) Draw something.
5. Delete Surface.
6. UnMake the Context from current.
7. Different crashes possible depending on Surface type and what
is done in step 2.
Bug: angleproject:8017
Test: angle_end2end_tests --gtest_filter="EGLSurfaceTest.DestroyNotCurrent*Surface*"
Change-Id: I3102aa237075b301b3222b420415753c83ba192a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4227073
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
0d0e8c37
|
2023-02-08T17:33:39
|
|
Vulkan: Fix mutable render buffer with protected content.
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>
|
|
|
7da34485
|
2023-01-17T16:17:51
|
|
Vulkan: Changed "asyncCommandQueue" Pending Present info logic.
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:
31c4093651079775acf34ea1bb06bdabb4ea4386
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>
|
|
|
8b9bd182
|
2023-02-08T16:17:10
|
|
Vulkan: Refactoring to use ProtectionType enum instead of bool
This is a second stage of refactoring that was started here:
Vulkan: Minor CommandQueue implementation refactoring.
0210b46d35b51ea04bddafb48ba406a87c39e58e
Enumeration renamed: CommandContent -> ProtectionType.
Currently interfaces of ContextVk/RendererVk/CommandQueue use
"hasProtectedContent" boolean. Internally CommandQueue uses
"vk::ProtectionType" enumeration to separate states related to
Unprotected/Protected commands. This CL replaces boolean with
enumeration for consistency.
Bug: angleproject:7995
Change-Id: Ibb98cce661358d464be7c6a8367a1297d7093b1c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4232114
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
b6cc5754
|
2023-01-17T16:17:22
|
|
Vulkan: Fixed Wait Semaphores problems.
This feature fixes 2 problems.
1. Swapchain Image Acquire Semaphore added to wait list AFTER
rendering commands:
- Make Window Surface current.
- Clear Window Surface (Image is Acquired).
- Perform rendering to the Window Surface.
- Change to other Surface (for example: PbufferSurface) using
the same Context.
- Unmake Context from current to ensure commands are submitted.
- Rendering commands to the Window Surface will be submitted
without Acquire Semaphore.
2. Context from other thread may submit command of another Context
without proper Wait Semaphores:
- Make Window Surface current in the first context.
- Clear Window Surface (Image is Acquired).
- Perform rendering to the Window Surface.
- Call "glBeginQuery()/glEndQuery()" (or other commands) - this will
flush command to the Primary Command Buffer without submitting.
- In other Thread and Context make some Surface current
(for example: PbufferSurface).
- Clear that surface with scissor and unmake Context from current
to ensure commands are submitted.
- Rendering commands to the Window Surface from the first Context
will be submitted without Acquire Semaphore.
- Problem will happen even if add Wait Semaphore BEFORE writing
rendering commands.
Bug: angleproject:7995
Test: angle_end2end_tests --gtest_filter="EGLSurfaceTest.WaitSemaphoreAddedAfterCommands*"
Test: angle_end2end_tests --gtest_filter="EGLSurfaceTest.CommandsSubmittedWithoutWaitSemaphore*"
Change-Id: I28174ff98fdd09b4117962fc0810cfeeb2a4d1f1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194182
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
ac0a4a7d
|
2023-02-03T15:34:32
|
|
Add finer memory allocation type
... so that when we hit an OOM we have better understanding on why.
Bug: b/266466279
Test: trigger a Vulkan OOM, see detailed allocation logging info
Change-Id: I71c1ebd83e18ddb22e7abfd29a785bf4ad6454dc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4219365
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
28da0a3e
|
2022-11-28T14:43:10
|
|
Vulkan: Avoid swapchain recreation on present mode change
Bug: angleproject:7878
Change-Id: I5a36c206dc8feb640fc684f92c10c26628633601
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4088907
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jeff Vigil <j.vigil@samsung.com>
|
|
|
b96f3abd
|
2023-02-03T13:12:29
|
|
Vulkan: Make Context::mLastSubmittedSerial to QueueSerial
Right now Context::mLastSubmittedSerial and mLastFlushedSerial are all
Serial type instead of QueueSerial. Most places we do need QueueSerial.
This CL changes them to QueueSerial type. This simplifies and improves
code readability. No actual functional change is expected with this CL.
Bug: b/267806287
Change-Id: Ib00cae2637ee9ed95e5fc00060c63017b04e26c5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4219944
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
c98a413c
|
2022-11-28T13:56:10
|
|
Vulkan: Use deferred allocation for swapchains when possible
Bug: angleproject:7878
Change-Id: I539027f4fabe7a56f05280baee3772bc536791e6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4088906
Reviewed-by: Ian Elliott <ianelliott@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jeff Vigil <j.vigil@samsung.com>
|
|
|
ffbb65bc
|
2022-11-28T13:31:48
|
|
Vulkan: Use VK_EXT_swapchain_maintenance1 for present fences
Bug: angleproject:7878
Change-Id: Ic3a43c663789a6489cff261848d9ad4a408ca53a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4088905
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
f1872822
|
2022-12-22T17:17:37
|
|
Vulkan: Fix imageless framebuffer VVL issue
In some tests, including some blink tests, there were cases of VVL
messages spamming the output log, even though they did not always
cause a failure. Investigation showed that in some cases, the call
to EGL_CreateImageKHR() was not setting all the attributes in the
ImageHelper object that is used later for an imageless framebuffer,
specifically the one created in VkImageImageSiblingVk::initImpl().
* Added the usage flags and view formats in the new image created in
VkImageImageSiblingVk.
* Added a Vulkan image test to make sure the error is fixed.
Bug: b/261473248
Bug: angleproject:7845
Change-Id: I1874b2930e9ce62e5b603cf7acff6fd78b957d5b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4117584
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
02cc4cd5
|
2022-12-07T12:03:26
|
|
Vulkan: Remove ImageHelper::mImageAndViewGarbage
This was introduced in crrev.com/c/3449450. At that time this is
necessary, because we can not copy mUse for immediate view garbage
collection. Now with recent work, mUse is copyable, we no longer need to
accumulate the view garbage. They can be released immediately with a
copy of image's mUse.
Bug: b/261737134
Change-Id: Ic4393f8c4ee7c0e3be4669a0a557507c909a77ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4087323
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2e5ca217
|
2022-11-18T10:44:49
|
|
Vulkan: Let each current context has its own QueueSerial.
This CL makes every current context has its own queueSerial. At context
creation time or when context becomes current, it allocates a QueueIndex
from renderer. When it becomes non-current, it releases QueueIndex for
others to reuse. This way we significantly reduces the max number of
QueueIndexs for reasonable usage. Each CommandBuffer has its own unique
QueueSerial and we use that to determine if a resource is being used by
the given CommandBuffer. The QueueSerial for RenderPassCommands is
deferred until renderPass starts, and when we generate queueSerial for
renderPassCommands, we also reserve a range of serials for
outsideRenderPassCommands so that we can do incremental submission of
outsideRenderPassCommands without need to close renderPassCommands. In
rare situation, if that reserved serials runs out, we also close
renderPassCommands to ensure the ordering of serials matches ordering of
command buffers.
With per current context queue serial, this CL is able to set resource
queue serial as it is being used. This CL completely removes usage of
ResourceUseList class since it was introduced due to deferred setSerial.
This CL also get rid of refCount from ResourceUse since there we no
longer add it to a ResourceUseList. With that, we also able to remove
SharedResourceUse class since access to ResourceUse itself is now thread
safe since we are able to make a copy of it when we add it to
GarbageList.
Because RenderPassCommands now has its own unique QueueSerial as it
encodes command, we can use it to detect if a resource is being used by
it or not, thus this CL also removes usage of CommandBufferID.
Bug: b/255414841
Change-Id: I36dcbeaa7bc996f04e6c04bf9ad44cd0d630f61a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4038096
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2ecb3217
|
2022-11-28T15:24:39
|
|
Vulkan: Turn CPU throttling into fail safe
CPU throttling is moved back to after queue present instead of before.
Doing it before was a mistake, as the app had already recorded the
command buffers, there was no point in delaying its submission.
Proper throttling would have been moving the wait from after recording
commands (before present of frame i+2) to before recording (after
present of frame i+1). However, throttling is the responsibility of the
app and this change triggers throttling one frame later (after present
of frame i+2) as a fail safe.
Currently, CPU throttling is relied upon for acquire semaphore
recycling. If the two are untangled, CPU throttling can be removed.
CPU throttling can also be trivially weakened by increasing
kSwapHistorySize (currently 2).
Bug: angleproject:7268
Change-Id: Ib7a8be6f8e72c6b8589d4e8b5de7ceaf6a28bb8e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4060454
Reviewed-by: Ian Elliott <ianelliott@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
31c40936
|
2022-11-25T12:28:27
|
|
Vulkan: Rework present semaphore recycling
Present semaphores and old swapchains are now associated with a fence
for clean up. The fence is the one coming from the _next_ acquire of
the same image index.
See doc/PresentSemaphores.md for more details.
Bug: angleproject:7847
Change-Id: I16891ccf6df7ac39d8b17328aac35afc422eede0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4058286
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
7dd8478e
|
2022-11-17T10:11:02
|
|
Vulkan: Make ResourceUse::serial an FastVector of Serials
In preparation for per context queue serial, this CL makes
ResourceUse::serial a FastVector of Serial. Right now we still limited
to one serial index so that it still work the same way as before. This
CL adds necessary data type and change the function names to reflect
that tracking GPU progress needs a ResourceUse object instead of a
single Serial number.
Bug: b/255414841
Change-Id: Ic60cdf5ec8da45d1821f65a55947f5c553f65737
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4034548
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
1b88c41f
|
2022-10-31T10:58:09
|
|
Vulkan: Remove the disableFifoPresentMode feature
Workaround was added for old Intel bots, no longer applicable.
Bug: angleproject:3153
Change-Id: Ib248927fbb1be33d8bd89a0c8185761f7f1ed6fa
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3993361
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
|
|
|
c19ec948
|
2022-08-23T10:43:59
|
|
Vulkan: Implement imageless framebuffers
* Added the attachment image and create info objects to be used
for imageless framebuffers created in getFramebuffer().
* New helper class for framebuffers in RenderPassCommandBufferHelper:
MaybeImagelessFramebuffer, which includes a framebuffer object, if
the framebuffer is imageless, and the image views. This is to make
sure that the args for render pass begin info will be correctly set
up according to the status of the used framebuffer.
* Refactored the collection of attachments in getFramebuffer() into
a new function, getAttachmentsAndImagesFromRenderTargets(). It also
returns their corresponding ImageHelper* objects used to create the
framebuffer (from their image properties).
* New struct: RenderTargetInfo; which keeps track of render targets
and whether resolve image should be used for the render pass in the
form of the enum class RenderTargetImage.
* Added a new arg to getFramebuffer(): resolveRenderTargetIn; to use
when there is a valid resolveImageViewIn.
* Without using the framebuffer cache, we would require to handle
the framebuffer destruction by adding it to the garbage instead
of releasing it. For example, FramebufferVk::destroy() now adds
mCurrentFramebuffer to the garbage.
* Added new framebuffer unit tests.
* Added tests where two textures with different attributes are bound
to the same framebuffer before drawing, one after another.
* Added test where a blit occurs from a multisample texture into a
non-zero level of a resolve texture, each bound to a separate FBO.
* Added a new perf test to compare performance for enabled imageless
framebuffers vs disabled. (Credit: cclao)
Bug: angleproject:7553
Change-Id: Iacdbd73aaa01cbb0e37abf01ae4892bdfdd4b12f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827644
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
a8a04ce1
|
2022-08-16T17:59:20
|
|
Vulkan: Add supportsPresentation feature
Some platforms do not support presentation through any Vulkan queue. In
this case we should not transition the color image layout to present.
Bug: angleproject:7217
Change-Id: I71cad0e52bc1fdb531de5a34e917a1862a4cf070
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Suggested-by: Sungyong Choi <sywow.choi@samsung.com>
Suggested-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3853598
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ae971cfe
|
2022-09-07T17:00:17
|
|
Vulkan: Expose wide gamut and HDR EGL colorspace extensions
Query the underlying Vulkan ICD for the list of supported colorspaces
on platforms that support VK_GOOGLE_surfaceless_query extension.
Expose corresponding EGL colorspace extensions.
Bug: angleproject:7630
Change-Id: If9843ee55100fff5a8cec4ecf2ff27c746c5b205
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3873767
Reviewed-by: Trevor Black <vantablack@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|