This CL is intended to be trivial. It marks the return from `std::to_array` as
`constexpr`. This CL is a split of a naive textual search-and-replace under:
gpu/command_buffer
This CL was uploaded by git cl split.
Change-Id: I9df0a50e5c9945e81126a4e2173e1d736021ce27
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6299473
Auto-Submit: Kalvin Lee <kdlee@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1424420}
An upcoming change will require a unittest to pass in a
SharedImageUsage. This CL adds that API as well as a general-purpose
API that takes in SharedImageMetadata and that the various convenience
APIs are now all backed by.
Bug: 40064122
Change-Id: I27f55414173e4fb5cbde319aeb19ebfb88fd7e81
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6297683
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1424347}
Update SharedImageVideoFrameData mojom struct to take in
is_mappable_si_enabled passed in by the VideoFrame to check for
mappable shared image support. Based on the flag, use
WrapMappableSharedImage to create a mappable VideoFrame passing in
the ExportedSharedImage that contains the GpuMemoryBufferHandle.
Make this conversion behind a killswitch to guard against rollout
issues.
Bug: 391865297
Change-Id: Iba04429ce1d09bddc21cdb977edf9bd705c03511
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6287668
Commit-Queue: vikas soni <vikassoni@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Eugene Zemtsov <eugene@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: vikas soni <vikassoni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1423518}
Recent SharedImage changes always assumed the presence of a D3D11
device. When graphite runs with D3D12, no D3D11 device was provided
to the D3DImageBackingFactory constructor, causing it to crash
At the same time, since InitializeDirectComposition is always called
with ANGLE's D3D11 device, it incorrectly, returned true for
IsD3DSharedImageSupported and crashed when the renderer process sent
it scanout images.
The CL rearranges GPU initialization such that DirectComposition is
initialized after the Dawn context provider, thus providing it the
correct D3D11 device, or no D3D11 device if there is none.
IsD3DSharedImageSupport is provided with the SharedContextState so it
can learn the truth about there being no D3D11 device.
With these changes, D3DSharedImageFactory is never created and no
scanout images are requested from the renderer process. Graphite on
D3D12 boots and is able to draw basic web pages.
Future CLs will slowly bring back SharedImage capability when Graphite
runs on D3D12.
Bug: 396312708
Change-Id: I30860ecd523eb158e57b2c65f9be4d6ce246fbcc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6288547
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Rafael Cintron <rafael.cintron@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1423478}
Previously we initialized persistent dawn's access two early,
DawnSharedTextureHolder didn't have a chance to cache the shared texture
memory. Hence the texture wasn't destroyed when the
DawnSharedTextureHolder is deleted. Leading to memory leaks.
Fix by attempting to cache the shared texture memory before initializing
the persistent dawn's access.
Bug: 354942507
Change-Id: I7fd752cfb41d51f5f17e94b6c46b3f8020bdf6c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6290929
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Auto-Submit: Quyen Le <lehoangquyen@chromium.org>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1423378}
DecoderPerfTest.ProgramDraw was failing due to not
waiting for commands to process after each iteration which
would result in the gpu being overwhelmed and running
out of memory as well as skewing iteration timing
since commands would keep piling up.
Fixed issue by forcing each replay to wait for commands execution.
Change-Id: I370b468c09ef1517cb94f3b3c7530d352adc1ac1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6252629
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1423209}
Previously we checked whether we need to disable persistent dawn's
access if the D3DImageBacking has dxgi_shared_handle_state_. However, if
the backing has a dcomp texture, cross device synchronizations are also
required, thus we need to disable persistent dawn's access as well.
Bug: 354942507
Change-Id: I72a01bfa3d91b850ec5fdde78f806679fb9019ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6289654
Auto-Submit: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Colin Blundell <blundell@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1423074}
When D3DImageBacking is not shared across devices, such as when using
a pure ID3D11Texture2D instead of a shared handle, we don't need any
fence to sync between Graphite & ANGLE because both use the same D3D11
device.
- Hence we can call SharedTextureMemory.BeginAccess once and keep it
open until the backing is destroyed.
- To make graphite's commands visible to ANGLE, we will trigger
Context::submit before we access in ANGLE, this is done at the start
of BeginAccessD3D11.
- After ANGLE modifies the texture's content we need to notify Dawn
that the texture has been initialized. It is to avoid Dawn lazily clears
the texture again. The only way to do this is via SharedTextureMemory's
BeginAccess. However since we keep the access open, we will need to
temporarily end SharedTextureMemory's access and call BeginAccess again.
This is done at the end of EndAccessD3D11.
Bug: 354942507
Change-Id: Ia3a69dbf40f19078777da06c7676927c93ad7364
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6271343
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Auto-Submit: Quyen Le <lehoangquyen@chromium.org>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1423003}
This CL changes moves the DComp texture available fence acquisition from
immediately before the subsequent write to immediately after retiring
the texture.
This change moves the possible case of failure to acquire the available
fence to the frame with a problematic DComp commit, rather than a later
rasterization task.
This is valid because DComp commit is not an event that affects the
validity of the available fence, as previously thought. As long as the
DComp texture is not placed back into any visual tree and we do not
release the DComp texture, the available fence remains valid.
Change-Id: I96be19a6271eda6d9f5060baf837059909b63204
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6271326
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Michael Tang <tangm@microsoft.com>
Reviewed-by: Rafael Cintron <rafael.cintron@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1422796}
This function is ES3.1+ and was used only to query the first draw buffer
when the regular glGetBooleanv already queries that value.
Bug: 397919896
Change-Id: I0162b772e5d969702d6ba25fb1ccc09b64762d30
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6287146
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1422776}
Display the plumbed in SkiaBackendType in GpuInfo in about://gpu page.
This information is useful for debugging in cases where the
SkiaGraphite or Vulkan feature information is not enough.
Bug: 364913797
Change-Id: I67ff7a8dd5e100fcfb1dc1f0d0476f85a4cbcef5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6278041
Reviewed-by: Kyle Charbonneau <kylechar@chromium.org>
Commit-Queue: Saifuddin Hitawala <hitawala@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1422712}
Add SkiaBackendType info to GpuInfo. This moves the SkiaBackendType
from SharedContextState to GpuPreferences so that it can be shared
more easily. Also update the relevant mojom files.
This will be later displayed in chrome://gpu information.
Bug: 364913797
Change-Id: I588652fd8babe17d28061ac39c4df909e6e38ada
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6282205
Reviewed-by: Kyle Charbonneau <kylechar@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Commit-Queue: Saifuddin Hitawala <hitawala@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1422176}
Add optional BufferUsage param to ExportedSharedImage. Also update the
corresponding mojo.
Update ClientSharedImage ctor to directly take in ExportedSharedImage
instead of the params passed over from it.
Bug: 391788839
Change-Id: I0e1eeca01e61bd440aa42ec77b11be0f11f87a7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6258397
Reviewed-by: vikas soni <vikassoni@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Saifuddin Hitawala <hitawala@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1420799}
Add an optional GpuMemoryBufferHandle to ExportedSharedImage in
order to be passed over mojo. This change adds optional GMBHandle to
ExportedSharedImage and updates callers of ExportedSharedImage.
It also updates Export, ImportUnowned and ClientSharedImage ctors
based on the ExportedSharedImage with GMBHandle.
NOTE: Creation of GpuMemoryBuffers requires BufferUsage which will
be added in follow-up. We'd also like to add a bool in follow-ups
that specifies if Export() should export a cloned handle or
not based on clients that require it.
Inspired from https://chromium-review.googlesource.com/c/chromium/src/+/5737963
by Vikas.
Bug: 391788839
Change-Id: Iee51901b98fb73a5898ad01cb45412956102d8a0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6207476
Reviewed-by: vikas soni <vikassoni@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Commit-Queue: Saifuddin Hitawala <hitawala@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1420769}
There can be cases where a crash happens and chrome can fallback
from Graphite to Ganesh. In such cases the gr-context-type crash key
is overwritten and the crash report can report incorrect information.
This change fixes by logging crash key once when Skia is initialized
the first time.
Bug: 390417678
Change-Id: I65a23a163356f4d9a439e3ecb4f5baefb4c3a676
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6264787
Commit-Queue: Saifuddin Hitawala <hitawala@chromium.org>
Reviewed-by: Kyle Charbonneau <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1420579}
As part of making ExportedSharedImage move only, update
ClientSharedImage::ImportUnowned to take in ExportedSharedImage
without const ref so that it can be moved over mojo.
Also update SharedImageInterface::ImportSharedImage to do the same.
Bug: 391788839
Change-Id: Iffe41753fe5ac79eb481c3c8f1ee0d64d0b6269f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6244979
Reviewed-by: vikas soni <vikassoni@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Commit-Queue: Saifuddin Hitawala <hitawala@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1418247}
When features::IncreaseBufferCountForHighFrameRate() returns true, the
value will be 5 instead of 3. This is fixing the tests to be more
flexible.
Bug: None
Change-Id: Ifbc3c40ac164d52e66cb496ce707e3b86ebd27b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6241994
Commit-Queue: Mounir Lamouri <mounir@meta.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417463}
WrappedGraphiteTexture backing can be used for test scenarios where
IOSurfaceImageBacking cannot be used with Graphite-Swiftshader-Vulkan
backend. One such scenario is PaintCanvasVideoRendererWithGLTest
unittest where the test takes 1-copy path with
CopySharedImageToGLTexture over passthrough command decoder which in
turn calls ProduceSkiaGanesh. Here since Swiftshader-Vulkan backend
is used for testing, WrappedGraphiteTexture backing is picked which
needs to implement ProduceSkiaGanesh for supporting the codepath to be
tested.
In production, the IOSurfaceImageBacking would instead be used as it
would support Scanout/Gles2 usages but WrappedGraphiteTexture backing
does not support such usages (only supported for testing).
Ideally, we should test with IOSurfaceImageBacking itself and something
we should look into.
Test: Tested PaintCanvasVideoRendererWithGLTest locally on M1 mac
with `--enable-skia-graphite` to make sure the test works expectedly.
Bug: 394385381
Change-Id: I97e78ae7861be6b91148489bbcf83402597ff319
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6237666
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Colin Blundell <blundell@chromium.org>
Commit-Queue: Saifuddin Hitawala <hitawala@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417373}
Add a SingleThreadTaskRunner to
ClientSharedImage::HelperGpuMemoryBufferManager.
HelperGpuMemoryBufferManager uses this task runner for
CopyGpuMemoryBufferAsync() operations to prevent deadlocks.
Deadlock Scenario:
1. Client thread calls CopyGpuMemoryBufferAsync() with a completion
callback.
2. Client thread blocks, waiting for an event which is often signaled by
the callback.
3. If the copy ran on the client thread, the callback would also need to
run on the *same*, now-blocked thread.
4. The callback can't run, the event isn't signaled, and a deadlock
occurs.
This dedicated task runner ensures the copy and callback execute
independently of the client thread, allowing the callback to signal the
event and prevent the deadlock.
Solution:
Bug: 40264379
Change-Id: If60083ace9eea92f08a96322d0d57910913e465a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6241072
Reviewed-by: Colin Blundell <blundell@chromium.org>
Auto-Submit: vikas soni <vikassoni@chromium.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@chromium.org>
Commit-Queue: vikas soni <vikassoni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417336}
Lacros is gone. Remove IS_CHROMEOS_LACROS and is_chromeos_lacros code
and replace IS_CHROMEOS_ASH and is_chromeos_ash with IS_CHROMEOS and
is_chromeos. Also remove obsolete imports of chromeos_buildflags.h
and chromeos/ui_mode.gni.
Bug: b:354842935
Change-Id: I6cf5a4d9cdc938a40fc9c7793ab1ff59e80645df
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6229170
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417143}
As part of adding GpuMemoryBufferHandle to ExportedSharedImage we add
move only constructors instead of copy constructors to ExportedSI.
This will allow to move the GMBHandle instead of cloning it when
assigning or copying the ExportedSharedImage.
This change adds a Clone method on ExportedSharedImage that allows
current clients of ExportedSharedImage to continue cloning it while
making the ExportedSharedImage mojo move only. This will allow
future usage with GpuMemoryBufferHandle to be moved around.
Bug: 391788839
Change-Id: I8c778a2dd9c326d0c85c349d10ae781e39cafba9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6237513
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Commit-Queue: vikas soni <vikassoni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417141}
Right now it uses SharedImageInterfaceInProcess which is fully
functional SII, but it needs only GetNativePixmap function that is just
forwarded to SharedImageInterface.
As we already have SharedImageManager around, it's easier to use that
and not create SIIInProcess. This would also allow to simplify few
things, because SkiaRenderer doesn't need to share it's sequence with
SII.
Change-Id: Ib04d5cde150482d86fca0fd02733c6e93c4a2943
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6237717
Reviewed-by: Kyle Charbonneau <kylechar@chromium.org>
Commit-Queue: Vasiliy Telezhnikov <vasilyt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417047}
Add flow trace events for sync token waits and releases. Make the
callback id a global static atomic so that it can uniquely identify a
sync token wait across all clients, and thus can be used as the flow
trace id.
Bug: 394772735
Change-Id: I54cddbe9903e292384c9bbdf524ff1353783940f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6239164
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Vasiliy Telezhnikov <vasilyt@chromium.org>
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417011}
Add flow trace events for the entire lifetime of a GPU scheduler task
from scheduling the task, unblocking it from sync token dependencies,
starting the task, continuing it, and finishing the task.
One small change in behavior is that we don't call Wait for a sync token
if it's for exact same sync token and order number. This should have no
effect other than one less no-op callback from being triggered - the
`wait_fences_` in `TaskGraph::Sequence` is a set so only one of the
callbacks will have any effect.
Other minor cleanup included:
1) Replace the front task unblocked callback with a virtual method that
subclasses can override.
2) Remove unnecessary CreateSequence methods from TaskGraph.
3) Add const qualifiers for some local variables in a couple of places.
Bug: 394772735
Change-Id: Ide719ee72ef66dda3eaf873c94dd5f1c0da9ff1b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6237782
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417007}
This CL relaxes our early CHECK that DWM is no longer reading our comp
texture to only happen when there are no other windows that could
possibly reference it.
This CHECK would previously cause crashes in debug builds in a race if a
window reuses a DComp texture before the retiring window releases it.
Bug: 368305211
Change-Id: I7ad34a7c9f580e14843a9e69b5b9d026f2856156
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6228143
Reviewed-by: Rafael Cintron <rafael.cintron@microsoft.com>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Michael Tang <tangm@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1416366}
Dawn can now supports direct AHardwareBuffer import on all Android
backends (with feature checks).
Changes from original CL: Fall back to EGLImage backing when the SyncFD
feature is not available. A follow-up patch will add new SharedFence
types for this case.
This is a reland of commit f5334a65d6
Bug: 42241435
Change-Id: Ib4bd11e5be4bf5bfdb17902a1a195c8bcaa9a594
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6207253
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1416337}
Update a python script to add unsafe libc call suppression to a list of
generated files, then run the scripts which use it to regenerate the
files.
This is similar to what was done in the past to suppress unsafe buffers
warnings, and helps prepare us for eventual enforcement of these
stricter warnings.
Bug: 390223051
Change-Id: I29898d1d7f5d9b010481e8b48cb26f37f6b56674
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6230978
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1416324}
