On ChromeOS, the gpu-process will AssertSingleThreaded() during
sandboxing. Therefore, we can't start the stack sampler (which creates a
thread) until after sandboxing.
BUG=b:214117401,chromium:1324337
Change-Id: Icfee509869f2bda9d2fe124a3146e8d98ef84708
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3764862
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Ian Barkley-Yeung <iby@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Mike Wittman <wittman@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1035308}
This is a no-op migration from base::ThreadPriority to base::ThreadType.
Except for the name changes of enum classes and functions, their
behavior should be kept unchanged. By using the new ThreadType API, the
caller declare the type of work a thread runs, and let the platform
implementation decide its behavior. Apart from the current priority
setting, the QoS API will further be used on some platforms.
Mappings in existing callers are as follows:
ThreadPriority::BACKGROUND => ThreadType::kBackground
ThreadPriority::NORMAL => ThreadType::kDefault
ThreadPriority::DISPLAY for compositing only on select
platforms (WIN, ANDROID, CrOS)
=> ThreadType::kCompositing
ThreadPriority::DISPLAY unconditionally on *all* platforms
=> ThreadType::kDisplayCritical
ThreadPriority::REALTIME_AUDIO => ThreadType::kRealtimeAudio
As this CL aims to make all platform-specific decisions in the
platform_thread_<platform>.cc impls, ifdef exceptions on main threads
(like on Mac) have moved to their respective impls.
The resulting callers should thus have no ifdefs left except for the odd
exception with a TODO we aim to unravel after this no-op CL.
ifdefs for render_message_filter()->SetThreadType() stay for now as this
call is already platform specific.
Bug: 1278628, 1324809
Change-Id: I36fbc4fc988c12e712da2e131595255a7b4fe4b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3329026
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Zhibo Wang <zhibo1.wang@intel.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Olga Sharonova <olka@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Peng Huang <penghuang@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Markus Handell <handellm@google.com>
Reviewed-by: Sergey Volk <servolk@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1021517}
This patch creates ThreadPool earlier, so that it's guaranteed to exist
before creating field trials. Now both field trials and the ThreadPool
always exist in PostFieldTrialInitialization.
A followup patch will use this entry point to start the heap profiler
in child processes.
Bug: 1327069
Change-Id: I2258fb77f06557460e342144e1c76de13985a4c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3654912
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1010574}
If the browser goes to background and back this will be reset. This cl doesn't yet handle setting the affinity to default value when the browser or renderer is in the background.
Bug: 1257237
Change-Id: I5cbdf4f6518d8d73acfe0aa3fcc1125b7428201b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3230003
Auto-Submit: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#932761}
Finch will be used to determine which threads run on big or bigger
cores. There's no logic yet to do this for just foreground renderers or
apps; the intent is to first gather data on what is the biggest
performance benefit this could yield along with the corresponding
worst-case power drain. The other purpose is to see how the numbers from
the field compare to what we see on Pinpoint.
Bug: 1257237
Change-Id: I5ddf996c8a4797c7787549a405c4c91e65e705c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3216304
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#931674}
Before using the libva, it must be initialized.
However, when chromium is started with --in-process-gpu,
the initialization call was missing and hence, the hardware acceleration
did not work.
This bugfix adds the missing initialization call.
Bug: 1032038
Change-Id: Id0635827aa0154330e3a0b85ab16faa215ede757
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1953730
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#723909}
gpu::GpuInit is used in the gpu process to initialize gpu related. Do
the same when gpu is initialized in the host process.
Instead of having InProcessGpuThread and content::GpuMain separately
owning their own GpuInit, move the ownership to GpuChildThread.
BUG=730213
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ic2964da3d4cd8a39a59d5b69ce74024a1685f88a
Reviewed-on: https://chromium-review.googlesource.com/695908
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#505936}
It was used to pass workarounds from browser process to GPU process, which is
no longer necessary.
Also, this CL wires up platform specific (GLX, EGL, WGL) disabled extensions
for in-process-gpu mode.
BUG=744658
TEST=gpu bots
R=kbr@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ic5d40229f8b6e5a65332b97449aee5ecfa7cd716
Reviewed-on: https://chromium-review.googlesource.com/641981
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498511}
That includes Chrome and WebView.
Note that we still do that on browser side. That will be removed soon once
we also move GPU blacklisting to GPU side.
BUG=744658
TEST=bots,manual with WebiewInstrumentation
R=piman@chromium.org,boliu@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I007c201ad4806dec35df9872132c4e5cd57bf20d
Reviewed-on: https://chromium-review.googlesource.com/641975
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498295}
This flag prevents the collection of gpu info on the multi-process path,
but not on the in-process path. This change makes the in-process path
consistent with the multi-process path.
This is needed by Cast for Android Things, which doesn't always have an
implementation of EGL, so crashes when loading gpu info.
Bug: None
Test: CQ
Change-Id: Ic700fe28c4c3b5af10cf860e76f43facba25d86d
Reviewed-on: https://chromium-review.googlesource.com/596329
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Thoren Paulson <thoren@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491400}
Move GpuMemoryBufferFactory ownership into GpuService. Some additional
cleanups:
. Update GpuMemoryBufferFactory::CreateNativeType() to return nullptr
when native buffers are not supported, instead of the callers having to
explicitly check first (using GetNativeGpuMemoryBufferType()).
. InProcessGpuThread::gpu_preferences_ is never used. So remove.
. Some now unnecessary #includes.
BUG=none
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/2781293003
Cr-Commit-Position: refs/heads/master@{#461337}
Right now OzonePlatform::InitializeForGPU() gets called as part of
gl::init::GetAllowedGLImplementations(). We need to properly set
InitParams when initializing the Ozone GPU so the platform knows if it
should expect to be running in a single process.
Instead, have the GpuInit or tests call InitializeForGPU(). This way
GpuInit can set InitParams::single_process to false and tests can set
InitParams::single_process to true.
Since this CL updates all callers of OzonePlatform::InitializeForGPU()
to use the new version, we can also delete the deprecated version of the
function.
BUG=700142,620934
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/2749873002
Cr-Commit-Position: refs/heads/master@{#457266}
This change moves decision making about whether to use GPU raster
from the browser process to the GPU process. This allows the
decision to be made based on more detailed GPU information, which
is not available to the browser. The new decision making process
is as follows:
The GPU process loads the GPU blacklist at startup, using more
complete GPUInfo than is available to the browser. This data is
combined with flags (forwarded from the browser) to
generate a GpuFeatureInfo struct which contains enabled/
blacklisted/disabled values for each GPU feature (currently
only populated for GPU raster).
The GPU process notifies the browser of its decision
by passing the GpuFeatureInfo via GpuHostMessage_Initialized.
The browser uses this info solely to populate about:gpu.
The GPU process notifies the renderer process of its decision
via context capabilities. The renderer uses this info to make
decisions on how to rasterize.
In the Render process, we now recieve GPU raster information
at a later point (when we create our CompositorFrameSink), so
we can't store this info in LayerTreeSettings. This requires
a bit of refactoring to have tests use context Capabilities
rather than LayerTreeSettings to provide this information.
BUG=648493
R=zmo@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/2654993004
Cr-Commit-Position: refs/heads/master@{#449729}
This CL delegates picking a transparent visual to the GPU
process. Previously, the browser process did not have enough
information to decide which visual to use because it couldn't get
GL-specific visual information directly. On Nvidia drivers,
picking the wrong transparent visual made the browser unusable.
Main changes introduced:
* Remove command line arguments window-depth, x11-visual-id, and
disable_transparent_visuals.
* Remove driver bug DISABLE_TRANSPARENT_VISUALS
* GPU process picks an ARGB visual and a system visual (which may
be different from the default visual) and sends it back in GPUInfo
BUG=347333,369209,640170,640170
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/2347383002
Cr-Commit-Position: refs/heads/master@{#422274}
GpuChildThread itself never uses |gpu_preferences_|. However,
GpuChannelManager holds a reference to it. So remove it from
GpuChildThread, and have GpuChannelManager, which actually uses
it, own it instead.
BUG=none
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/2322893002
Cr-Commit-Position: refs/heads/master@{#417331}
Synchronous compositor used this include to insert its own
SyncPointManager instance to be used by the in-process GPU thread.
Remove that DEPS and add ContentGpuClient::GetSyncPointManager so that
GPU code can directly get a SyncPointManager from content embedder. This
works for out of process GPU as well.
This also removes the InProcessCommandBuffer dependency from Android.
Review URL: https://codereview.chromium.org/1908223002
Cr-Commit-Position: refs/heads/master@{#389046}
GpuMemoryBufferFactory is a gpu service concept and should
not be accessed from the client.
Client code accessed GpuMemoryBufferFactory to get the
native GPU buffer type and to check whether a provided
buffer is supported. Depending on GpuMemoryBufferFactory
ends up pulling in other service-only bits.
This CL addresses this issue. The two static methods
accessed by clients are pulled into a new class:
GpuMemoryBufferSupport placed in gpu/ipc/common.
BUG=597170
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
Review URL: https://codereview.chromium.org/1831513003
Cr-Commit-Position: refs/heads/master@{#382987}
Up the priority of the browser and GPU process IO threads as some of its
IPCs relate to display tasks. This is consistent with Android except in
the case of ChromeOS we avoid increasing the priority of all IO threads.
BUG=internal b/26877099
Review URL: https://codereview.chromium.org/1690173004
Cr-Commit-Position: refs/heads/master@{#375506}
This would be very helpful for analyzing traces.txt of ANR logs.
BUG=570819
Review URL: https://codereview.chromium.org/1518213002
Cr-Commit-Position: refs/heads/master@{#365953}
BUG=521755
TEST=Manually tested MojoMediaApplication in GPU process and GPU thread in the browser process (--in-process-gpu).
Review URL: https://codereview.chromium.org/1297953004
Cr-Commit-Position: refs/heads/master@{#353453}
This makes it easier to add type specific tests and cleans up a lot
of code as a factory implementation is not longer needed for
shared memory.
BUG=538325
Review URL: https://codereview.chromium.org/1389133002
Cr-Commit-Position: refs/heads/master@{#352930}
Allow SyncPointManager instance to be set, and set the same
instance in Android WebView. Also remove ref-counting and just
guarantee SyncPointManager outlives running message loop.
Also make SyncPointManager thread safe, and callbacks are no longer
guaranteed to happen on the same thread. Make sure command buffer
implementations handle it correctly.
BUG=509702
Review URL: https://codereview.chromium.org/1231263003
Cr-Commit-Position: refs/heads/master@{#339712}
Also add the startup message filter for CreateGpuMemoryBuffer
messages in single process mode.
BUG=497559,504121
Review URL: https://codereview.chromium.org/1221473003
Cr-Commit-Position: refs/heads/master@{#336495}
The globally-set TaskRunner doesn't work because some child
thread can run inside the browser process even when other
child threads run in their own processes.
For example, there is a configuration where GpuChildThread
being in-process while RenderThreadImpl isn't.
It is troublesome once non-renderer child processes adopt
ChannelMojo.
This CL eliminates the global in-process IO task runner
and instead, passes an IO runnner for each thread
if it is configured as an in-process mode.
Note that InProcessChildThreadParams object is introuced to
clarify that the parameter is for in-process mode.
This is a spin-off from https://codereview.chromium.org/960693003/.
R=jamesr@chromium.org, rockot@chromium.org, jam@chromium.org
BUG=377980
Review URL: https://codereview.chromium.org/987693005
Cr-Commit-Position: refs/heads/master@{#321047}
Upon BrowserMainRunner::Shutdown(), InProcessGpuThread sometimes (race condition)
terminates simply by exiting the message loop due to closed RPC channel, the
ThreadWasQuitProperly flag is required to signal correct termnation in this
case.
BUG=
Review URL: https://codereview.chromium.org/323513003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@275848 0039d316-1c4b-4281-b951-d872f2087c98
