New issue
Advanced search Search tips

Issue 859719 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 898513



Sign in to add a comment

Move Vulkan initialization to where it belongs

Project Member Reported by cblume@chromium.org, Jul 3

Issue description

Currently, Vulkan initialization happens in the GPU process at a point where blocking operations shouldn't happen. We had to add an exception to the no blocking enforcement.

OpenGL code is initialized elsewhere, where it is allowed to block. We should move the Vulkan init to behave like the OpenGL init.
 
I investigated this. It seems like we are okay for now. We'll want to revisit this once we no longer need the prototype.

Context:

While setting up the prototype, we added an exception to blocking calls so we could load the dynamic library: https://cs.chromium.org/chromium/src/content/browser/compositor/gpu_process_transport_factory.cc?l=1035&rcl=7a954e099711e68c3bad517777f0867127247bc3

This made it obvious that we need to initialize Vulkan in the correct place.

While investigating the correct place to initialize I found there already is Vulkan initialization there: https://cs.chromium.org/chromium/src/gpu/ipc/service/gpu_init.cc?l=183&rcl=2f3569a4f414b420349e6251721c84bdea8fac4e
The catch is, this is never actually being hit. I suspect as work on OOP-D + Vulkan progresses it will eventually be hit.

Once we no longer need the prototype we can remove the exception to blocking calls. Until then, I think this is on pause.
Labels: vulkanize
Blocking: 898513
Labels: -vulkanize Proj-Vulkanize

Sign in to add a comment