[Impeller] Use the IO context for OpenGL program setup#37
[Impeller] Use the IO context for OpenGL program setup#37xiaowei-guan wants to merge 24 commits into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors PipelineCompileQueue into an abstract base class and introduces backend-specific subclasses, PipelineCompileQueueGLES and PipelineCompileQueueVulkan, to handle pipeline compilation scheduling. It also updates GLES context creation and platform views to pass an IO task runner. Feedback on these changes highlights that the abstract PipelineCompileQueue still declares an unimplemented static Create method and constructor, which should be removed. Additionally, a null check for the task runner should be added to PipelineCompileQueueVulkan::Create along with a corresponding unit test, and the mutex lock scope in PipelineCompileQueueGLES::OnJobAdded should be minimized to prevent potential deadlocks when calling external functions.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Because IO thread is the owner of resource context, pipeline library gles can load resource by IO thread.
…inish before starting the next one.
1.Change is_processing type to bool. 2.Change DoOneJob,PostJob,HasPendingJobs to protect.
1.Extrac a new method OnJobAdded 2.Replace std::mutex with Mutex 3.Add null check for io task runner 4.Change mthod ProcessJobsSequentially to private
1.Remove not used code. 2.Add comments for io task runner. 3.Remove io task runner from pipeline library gles.
There was a problem hiding this comment.
Code Review
This pull request refactors PipelineCompileQueue into a base class and introduces backend-specific implementations, PipelineCompileQueueGLES and PipelineCompileQueueVulkan, along with corresponding unit tests. It updates ContextGLES and PipelineLibraryGLES to accept and utilize an IO task runner for scheduling pipeline compilation. Feedback on these changes identifies that the asynchronous pipeline generation task in PipelineLibraryGLES does not synchronize with the GPU thread, potentially flooding the reactor queue and defeating the purpose of the compile queue. Additionally, a missing null check for the worker task runner in PipelineCompileQueueVulkan::Create could lead to a null pointer dereference.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
1 participant
Impeller eagerly sets up the entire set of pipeline state objects (PSOs) it may need during renderer setup. This works fine on mid to high-end devices as the setup completes well before the first frame is rendered.
However on low-end devices, not all PSOs may be ready before the first frame is rendered. Low-end device usually don't have as much available concurrency and are slower to boot. On these devices, the rendering thread had to wait for the background compile job to be completed. It was also observed that the relatively higher priority render thread was waiting on a background thread to finish a PSO compile job. The PSO compile job could also be stuck behind another job that was not immediately needed. This made the situation on low end devices less than ideal.
flutter#180022, this PR fix PSO stuck issue for Vulkan on low end devices.
Current PR can fix the PSO stuck issue for GLES on low end devices. Related issue : flutter#176657
This PR can improve app startup time for impeller+GLES on low-end devices.
flutter#180022 has provided solution for impeller + vulkan.
Impeller+GLES has a special case: resource loading cannot be arbitrarily placed on other threads; it needs to be done on the I/O thread because this thread shares the context with the GPU thread. Therefore, this PR introduces the I/O task runner into PipelineCompileQueueGLES. However, since the I/O task runner may handle other tasks, we cannot put all jobs into the I/O thread at once. My current solution is to wait for the previous job to finish before putting the next one into the I/O thread.
Main changes:
Introduce fml::RefPtrfml::TaskRunner into PipelineCompileQueueGLES.
Extract new class PipelineCompileQueueVulkan for vulkan, because the runners are on different threads.