From 060c38ed42ffd255f4cd591ad187c4ebb43fff43 Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 10:15:34 -0700 Subject: [PATCH 01/12] Wrote design doc for parallel gles compilation --- rfc/200.0001-parallel-gles-linking.md | 276 ++++++++++++++++++++++++++ 1 file changed, 276 insertions(+) create mode 100644 rfc/200.0001-parallel-gles-linking.md diff --git a/rfc/200.0001-parallel-gles-linking.md b/rfc/200.0001-parallel-gles-linking.md new file mode 100644 index 0000000..5f2c31f --- /dev/null +++ b/rfc/200.0001-parallel-gles-linking.md @@ -0,0 +1,276 @@ +--- +type: rfc +rfc: '200.0001' +title: Parallel OpenGLES Linking in Impeller +description: Outlines how Impeller will implement parallel shader compilation with the OpenGLES backend. +status: draft +created: 2026-10-09T00:00:00Z +updated: 2026-10-09T00:00:00Z +tags: +authors: + - '"Aaron Clarke" ' + - '"Evan Walley" ' +--- + +## Background + +On backends like Vulkan and Metal we are able to precompile shaders at +compile-time. For the OpenGLES backend we need to compile them at runtime. The +API provides a few functions to help make that happen: + +- [glCompileShader](https://registry.khronos.org/OpenGL-Refpages/es3.0/html/glCompileShader.xhtml) +- [glLinkProgram](https://registry.khronos.org/OpenGL-Refpages/gl4/html/glLinkProgram.xhtml) +- [GL_LINK_STATUS](https://registry.khronos.org/OpenGL-Refpages/gl4/html/glLinkProgram.xhtml) + +The OpenGLES standard doesn't specify exactly when the linking needs to be done, +it just has to be realized before it's actually used. This allows some drivers +to allow parallel compilation jobs to happen at the same time. Currently +Impeller is not taking advantage of this. It is instead serially issuing +compilation jobs and querying the `GL_LINK_STATUS` which forces synchronization +on the compilation job. + +In Impeller we work with Pipelines, but from the OpenGLES perspective there are +programs and there are pipelines. A program represents a compiled bundle of +shaders, for example a vertex shader and a fragment shader. A pipeline +represents a variant of those compiled shaders, for example with specialization +constants set. Programs can be shared across pipelines and they have their own +cache. + +## Technical Details + +The PipelineLibraryGLES design as it stands today is not well suited to handle +parallel compilation jobs. For one thing, the logic for the PipelineLibraryGLES +class is split among 3 different classes: PipelineLibraryGLES, +PipelineCompileQueue, PipelineCompileQueueGLES. This makes it difficult for us +to reason about and make the necessary changes. The following refactors will +first need to be redone: + +- Delete PipelineCompileQueue - It's artificially making the Vulkan compile + queue and the OpenGLES queue behaves similarly for no reason. There is one + place in the code that grabs the queue from the library and talks to it + directly to eagerly perform a job. That request should come through the + library directly. +- Create a class to represent pending programs - This will allow us to maintain + the concept of a compiling program when it no longer is a synchronous + operation. + +### Class diagram + +Here's what things will look like after the refactoring. + +``` +@startuml + +class CompileJob { + - descriptor + + {abstract} Start() + + {abstract} Finish() +} + +class BasicTaskRunner { + + {abstract} PostTask(task) +} + +class ReactorGLES { + + React() +} + +class PipelineCompileQueueGLES { + - supports_parallel_compile + - max_inflight_compile_jobs + - outstanding_jobs : atomic +} + +PipelineCompileQueueGLES *-- BasicTaskRunner +PipelineCompileQueueGLES *-- "*" CompileJob +PipelineCompileQueueGLES *-- "* compiling" CompileJob + +class PipelineLibrary { + + GetPipeline(descriptor, async : bool) : PipelineFuture + + {abstract} GetPipeline(descriptor, async : bool, threadsafe : bool) : PipelineFuture +} + +class PipelineLibraryGLES { + - programs : ProgramMap + - pipelines : PipelineMap + - CreatePipeline(library, descriptor, vert, frag, threadsafe : bool) : PipelineGLES + - LinkProgram(reactor, pipeline, vert, frag) : bool +} + +PipelineLibrary <|-- PipelineLibraryGLES +PipelineLibraryGLES *-- ReactorGLES +PipelineLibraryGLES *-- "*" PipelineFuture +PipelineLibraryGLES *-- PipelineCompileQueueGLES +PipelineLibraryGLES *-- "*" PendingProgram + +class PendingProgram { + + Compile() + + Wait() +} + +class PipelineFuture { + + descriptor + + future + + Get() : Pipeline +} + +@enduml +``` + +### Sequence diagram + +This shows how managing jobs will happen with the PipelineCompileQueueGLES and +the io thread. + +``` +@startuml +autoactivate on +participant raster as "(raster)" +participant io as "(io)" +participant library as ":PipelineLibraryGLES" +participant queue as ":PipelineCompileQueueGLES" +participant joba as "a:Job" +participant jobb as "b:Job" +participant jobc as "c:Job" +participant jobd as "d:Job" + +raster -> library : GetPipelineAsync + library -> queue : PostJobForDescriptor + queue -> io : ScheduleRun + return + return +return + +io -> queue : Run + queue -> queue : FinishOldestJob + note right: Happens because max pending links is hit + queue -> jobd : Wait + note right: glGetStatus(LINK_STATUS) + return + return + queue -> io : ScheduleRun + return +return + +io -> queue : Run + queue -> joba : Start + return + queue -> io : ScheduleRun + return +return + +raster -> library : GetPipelineSync + library -> queue : PerformJobEagerly + note right: Job is started but not completed + queue -> jobb : Wait + +io -> jobb : Wait() +return + + return + return +return + +raster -> library : GetPipelineSync + library -> queue : PerformJobEagerly + note right: Job is not started + queue -> jobc : ExecSync + return + return +return + +raster -> library : Delete + library -> queue : Delete + queue -> queue : FinishPendingJobs +io -> joba : Wait +return + return + return +return + +@enduml +``` + +### Pseudocode + +Here is the logic that will happen inside of the queue. It works recursively on +the io thread, doing one operation at a time and allows out of order +synchronization when an eager request happens from the raster thread. + +```dart +class PipelineQueue { + // Raster thread + void StartJob(Job job) { + _inactive_jobs.Add(job) + ScheduleRun() + } + + + // io thread + void Run() { + if (_eager_request){ + Job job = _active_jobs.Find(_eager_request); + _eager_request = null; + if (job) { + job.Synchronize(); + } + _condition_variable.Signal() + ScheduleRun() + } else if (_active_jobs.count < LIMIT) { + Job job = _inactive_jobs.Pop(); + job.Start(); + _active_jobs.Add(job); + ScheduleRun() + } else { + Job job = _active_jobs.Pop(); + if (job) { + job.Synchronize() + ScheduleRun() + } + } + } + + + // Raster thread + void RunEager(Desc desc) { + Job job = _inactive_jobs.Remove(desc); + if (job) { + job.Start() + job.Synchronize() + } else { + _eager_request = desc + ScheduleRun() + _condition_variable.Wait() + } + } +} +``` + +## Testing + +We already have the benefit of many high level integration tests. Since this +change is happening under the covers and at a critical point in rendering that +100% of renders will hit that will provide a lot of coverage. + +The new logic, parallel execution, will be exercised in unit tests on +PipelineCompileQueueGLES. The following cases should be be covered: + +- Destruction with outstanding pending jobs and active jobs +- Eager execution swaps the priority of synchronization of active jobs +- Hammering the queue enforces a limited number of jobs. + +## Alternatives considered + +### Use the `KHR_parallel_shader_compile` extension + +There is an extension that directly deals with parallel compilation of shaders. +It opens up an API that allows one to query the status of a compile job without +blocking. Previous attempts at fixing this problem used that API and guarded +parallel execution on the presence of that extension. + +That API is a polling API, there is no callback when compilation is complete. No +good heuristic could be thought up that does polling efficently without some +tradeoffs. It is also possible that a driver supports parallel compilation but +does not support the extension. By implementing the code with the assumption of +parallel compilation, the code is cleaner and we capture more potential benefits +if the drivers support it. From 670ab3445f57b36a5e1a2d833a4d467e44353eda Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 10:26:40 -0700 Subject: [PATCH 02/12] fixed authors --- rfc/200.0001-parallel-gles-linking.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc/200.0001-parallel-gles-linking.md b/rfc/200.0001-parallel-gles-linking.md index 5f2c31f..02206ed 100644 --- a/rfc/200.0001-parallel-gles-linking.md +++ b/rfc/200.0001-parallel-gles-linking.md @@ -8,8 +8,8 @@ created: 2026-10-09T00:00:00Z updated: 2026-10-09T00:00:00Z tags: authors: - - '"Aaron Clarke" ' - - '"Evan Walley" ' + - https://github.com/gaaclarke + - https://github.com/walley892 --- ## Background From 4827f8558e67b5fd9ea4462bc1d1c379e31bf093 Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 10:28:20 -0700 Subject: [PATCH 03/12] standardized semicolons --- rfc/200.0001-parallel-gles-linking.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/rfc/200.0001-parallel-gles-linking.md b/rfc/200.0001-parallel-gles-linking.md index 02206ed..042e0b5 100644 --- a/rfc/200.0001-parallel-gles-linking.md +++ b/rfc/200.0001-parallel-gles-linking.md @@ -209,20 +209,20 @@ class PipelineQueue { // io thread void Run() { if (_eager_request){ - Job job = _active_jobs.Find(_eager_request); - _eager_request = null; + Job job = _active_jobs.Find(_eager_request) + _eager_request = null if (job) { - job.Synchronize(); + job.Synchronize() } _condition_variable.Signal() ScheduleRun() } else if (_active_jobs.count < LIMIT) { - Job job = _inactive_jobs.Pop(); - job.Start(); - _active_jobs.Add(job); + Job job = _inactive_jobs.Pop() + job.Start() + _active_jobs.Add(job) ScheduleRun() } else { - Job job = _active_jobs.Pop(); + Job job = _active_jobs.Pop() if (job) { job.Synchronize() ScheduleRun() @@ -233,7 +233,7 @@ class PipelineQueue { // Raster thread void RunEager(Desc desc) { - Job job = _inactive_jobs.Remove(desc); + Job job = _inactive_jobs.Remove(desc) if (job) { job.Start() job.Synchronize() From b745ec8f9a03b6c07f8bee268e71a38b801ec2f9 Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 10:31:10 -0700 Subject: [PATCH 04/12] added heading --- rfc/200.0001-parallel-gles-linking.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfc/200.0001-parallel-gles-linking.md b/rfc/200.0001-parallel-gles-linking.md index 042e0b5..107a369 100644 --- a/rfc/200.0001-parallel-gles-linking.md +++ b/rfc/200.0001-parallel-gles-linking.md @@ -12,6 +12,8 @@ authors: - https://github.com/walley892 --- +# RFC 200.0001: Parallel OpenGLES Linking in Impeller + ## Background On backends like Vulkan and Metal we are able to precompile shaders at From 084dd056e62ef5a4dc4a358e95493a5ec88b9fe0 Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 10:34:37 -0700 Subject: [PATCH 05/12] added tag --- rfc/200.0001-parallel-gles-linking.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfc/200.0001-parallel-gles-linking.md b/rfc/200.0001-parallel-gles-linking.md index 107a369..68b65e8 100644 --- a/rfc/200.0001-parallel-gles-linking.md +++ b/rfc/200.0001-parallel-gles-linking.md @@ -7,6 +7,7 @@ status: draft created: 2026-10-09T00:00:00Z updated: 2026-10-09T00:00:00Z tags: + - 210-graphics authors: - https://github.com/gaaclarke - https://github.com/walley892 From 524a817e425c42d85147204ec6aecc58b047e9a3 Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 10:56:14 -0700 Subject: [PATCH 06/12] renamed --- ...llel-gles-linking.md => 200.0000-parallel-gles-linking.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename rfc/{200.0001-parallel-gles-linking.md => 200.0000-parallel-gles-linking.md} (99%) diff --git a/rfc/200.0001-parallel-gles-linking.md b/rfc/200.0000-parallel-gles-linking.md similarity index 99% rename from rfc/200.0001-parallel-gles-linking.md rename to rfc/200.0000-parallel-gles-linking.md index 68b65e8..2fa2ee8 100644 --- a/rfc/200.0001-parallel-gles-linking.md +++ b/rfc/200.0000-parallel-gles-linking.md @@ -1,6 +1,6 @@ --- type: rfc -rfc: '200.0001' +rfc: '200.0000' title: Parallel OpenGLES Linking in Impeller description: Outlines how Impeller will implement parallel shader compilation with the OpenGLES backend. status: draft @@ -13,7 +13,7 @@ authors: - https://github.com/walley892 --- -# RFC 200.0001: Parallel OpenGLES Linking in Impeller +# RFC 200.0000: Parallel OpenGLES Linking in Impeller ## Background From 39f53c1da173a16a4736083c85e4ad6010f7941c Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 11:15:58 -0700 Subject: [PATCH 07/12] added plantuml specifier --- rfc/200.0000-parallel-gles-linking.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc/200.0000-parallel-gles-linking.md b/rfc/200.0000-parallel-gles-linking.md index 2fa2ee8..9cb2bcd 100644 --- a/rfc/200.0000-parallel-gles-linking.md +++ b/rfc/200.0000-parallel-gles-linking.md @@ -61,7 +61,7 @@ first need to be redone: Here's what things will look like after the refactoring. -``` +```plantuml @startuml class CompileJob { @@ -125,7 +125,7 @@ class PipelineFuture { This shows how managing jobs will happen with the PipelineCompileQueueGLES and the io thread. -``` +```plantuml @startuml autoactivate on participant raster as "(raster)" From c50a2204e48f635752eacdea605d522e98a42d1b Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 12:44:34 -0700 Subject: [PATCH 08/12] feedback --- rfc/200.0000-parallel-gles-linking.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/rfc/200.0000-parallel-gles-linking.md b/rfc/200.0000-parallel-gles-linking.md index 9cb2bcd..f36c846 100644 --- a/rfc/200.0000-parallel-gles-linking.md +++ b/rfc/200.0000-parallel-gles-linking.md @@ -15,6 +15,13 @@ authors: # RFC 200.0000: Parallel OpenGLES Linking in Impeller +## Description + +This design doc lays out a refactoring of the pipeline compilation process on +Impeller OpenGLES that allows supporting backends to parallelize shader +compilation which will increase the likelihood that a shader is immediately +availble for use in the first frames of rendering. + ## Background On backends like Vulkan and Metal we are able to precompile shaders at @@ -39,6 +46,11 @@ represents a variant of those compiled shaders, for example with specialization constants set. Programs can be shared across pipelines and they have their own cache. +ANGLE supports parallel compilation, which is what Impeller uses on Windows. On +Android it doesn't seem to be as common. There isn't a direct check for support +but we can infer from the presence of the `KHR_parallel_shader_compile` +extension that some devices do support it. + ## Technical Details The PipelineLibraryGLES design as it stands today is not well suited to handle @@ -260,7 +272,7 @@ PipelineCompileQueueGLES. The following cases should be be covered: - Destruction with outstanding pending jobs and active jobs - Eager execution swaps the priority of synchronization of active jobs -- Hammering the queue enforces a limited number of jobs. +- Hammering the queue enforces a limited number of jobs ## Alternatives considered From 06e2d16be39837cf8784a32df80555180a309e37 Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 13:55:07 -0700 Subject: [PATCH 09/12] feeback --- ...llel-gles-linking.md => 210.0000-parallel-gles-linking.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename rfc/{200.0000-parallel-gles-linking.md => 210.0000-parallel-gles-linking.md} (99%) diff --git a/rfc/200.0000-parallel-gles-linking.md b/rfc/210.0000-parallel-gles-linking.md similarity index 99% rename from rfc/200.0000-parallel-gles-linking.md rename to rfc/210.0000-parallel-gles-linking.md index f36c846..b055120 100644 --- a/rfc/200.0000-parallel-gles-linking.md +++ b/rfc/210.0000-parallel-gles-linking.md @@ -1,6 +1,6 @@ --- type: rfc -rfc: '200.0000' +rfc: '210.0000' title: Parallel OpenGLES Linking in Impeller description: Outlines how Impeller will implement parallel shader compilation with the OpenGLES backend. status: draft @@ -13,7 +13,7 @@ authors: - https://github.com/walley892 --- -# RFC 200.0000: Parallel OpenGLES Linking in Impeller +# RFC 210.0000: Parallel OpenGLES Linking in Impeller ## Description From fd7e242b4cb8f893f79580e93925c5fa1e7eeb3a Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 14:00:38 -0700 Subject: [PATCH 10/12] switched to mermaid --- rfc/210.0000-parallel-gles-linking.md | 175 +++++++++++++------------- 1 file changed, 85 insertions(+), 90 deletions(-) diff --git a/rfc/210.0000-parallel-gles-linking.md b/rfc/210.0000-parallel-gles-linking.md index b055120..95d5a80 100644 --- a/rfc/210.0000-parallel-gles-linking.md +++ b/rfc/210.0000-parallel-gles-linking.md @@ -73,27 +73,27 @@ first need to be redone: Here's what things will look like after the refactoring. -```plantuml -@startuml +```mermaid +classDiagram class CompileJob { - - descriptor - + {abstract} Start() - + {abstract} Finish() + -descriptor + +Start()* + +Finish()* } class BasicTaskRunner { - + {abstract} PostTask(task) + +PostTask(task)* } class ReactorGLES { - + React() + +React() } class PipelineCompileQueueGLES { - - supports_parallel_compile - - max_inflight_compile_jobs - - outstanding_jobs : atomic + -supports_parallel_compile + -max_inflight_compile_jobs + -atomic~int~ outstanding_jobs } PipelineCompileQueueGLES *-- BasicTaskRunner @@ -101,15 +101,15 @@ PipelineCompileQueueGLES *-- "*" CompileJob PipelineCompileQueueGLES *-- "* compiling" CompileJob class PipelineLibrary { - + GetPipeline(descriptor, async : bool) : PipelineFuture - + {abstract} GetPipeline(descriptor, async : bool, threadsafe : bool) : PipelineFuture + +GetPipeline(descriptor, bool async) PipelineFuture + +GetPipeline(descriptor, bool async, bool threadsafe)* PipelineFuture } class PipelineLibraryGLES { - - programs : ProgramMap - - pipelines : PipelineMap - - CreatePipeline(library, descriptor, vert, frag, threadsafe : bool) : PipelineGLES - - LinkProgram(reactor, pipeline, vert, frag) : bool + -ProgramMap programs + -PipelineMap pipelines + -CreatePipeline(library, descriptor, vert, frag, bool threadsafe) PipelineGLES + -LinkProgram(reactor, pipeline, vert, frag) bool } PipelineLibrary <|-- PipelineLibraryGLES @@ -119,17 +119,15 @@ PipelineLibraryGLES *-- PipelineCompileQueueGLES PipelineLibraryGLES *-- "*" PendingProgram class PendingProgram { - + Compile() - + Wait() + +Compile() + +Wait() } class PipelineFuture { - + descriptor - + future - + Get() : Pipeline + +descriptor + +future + +Get() Pipeline } - -@enduml ``` ### Sequence diagram @@ -137,73 +135,70 @@ class PipelineFuture { This shows how managing jobs will happen with the PipelineCompileQueueGLES and the io thread. -```plantuml -@startuml -autoactivate on -participant raster as "(raster)" -participant io as "(io)" -participant library as ":PipelineLibraryGLES" -participant queue as ":PipelineCompileQueueGLES" -participant joba as "a:Job" -participant jobb as "b:Job" -participant jobc as "c:Job" -participant jobd as "d:Job" - -raster -> library : GetPipelineAsync - library -> queue : PostJobForDescriptor - queue -> io : ScheduleRun - return - return -return - -io -> queue : Run - queue -> queue : FinishOldestJob - note right: Happens because max pending links is hit - queue -> jobd : Wait - note right: glGetStatus(LINK_STATUS) - return - return - queue -> io : ScheduleRun - return -return - -io -> queue : Run - queue -> joba : Start - return - queue -> io : ScheduleRun - return -return - -raster -> library : GetPipelineSync - library -> queue : PerformJobEagerly - note right: Job is started but not completed - queue -> jobb : Wait - -io -> jobb : Wait() -return - - return - return -return - -raster -> library : GetPipelineSync - library -> queue : PerformJobEagerly - note right: Job is not started - queue -> jobc : ExecSync - return - return -return - -raster -> library : Delete - library -> queue : Delete - queue -> queue : FinishPendingJobs -io -> joba : Wait -return - return - return -return - -@enduml +```mermaid +sequenceDiagram +participant raster as (raster) +participant io as (io) +participant library as :PipelineLibraryGLES +participant queue as :PipelineCompileQueueGLES +participant joba as a:Job +participant jobb as b:Job +participant jobc as c:Job +participant jobd as d:Job + +raster->>+library: GetPipelineAsync + library->>+queue: PostJobForDescriptor + queue->>+io: ScheduleRun + io-->>-queue: return + queue-->>-library: return +library-->>-raster: return + +io->>+queue: Run + queue->>+queue: FinishOldestJob + Note right of queue: Happens because max pending links is hit + queue->>+jobd: Wait + Note right of jobd: glGetStatus(LINK_STATUS) + jobd-->>-queue: return + queue-->>-queue: return + queue->>+io: ScheduleRun + io-->>-queue: return +queue-->>-io: return + +io->>+queue: Run + queue->>+joba: Start + joba-->>-queue: return + queue->>+io: ScheduleRun + io-->>-queue: return +queue-->>-io: return + +raster->>+library: GetPipelineSync + library->>+queue: PerformJobEagerly + Note right of queue: Job is started but not completed + queue->>+jobb: Wait + +io->>+jobb: Wait() +jobb-->>-io: return + + jobb-->>-queue: return + queue-->>-library: return +library-->>-raster: return + +raster->>+library: GetPipelineSync + library->>+queue: PerformJobEagerly + Note right of queue: Job is not started + queue->>+jobc: ExecSync + jobc-->>-queue: return + queue-->>-library: return +library-->>-raster: return + +raster->>+library: Delete + library->>+queue: Delete + queue->>+queue: FinishPendingJobs +io->>+joba: Wait +joba-->>-io: return + queue-->>-queue: return + queue-->>-library: return +library-->>-raster: return ``` ### Pseudocode From 877b2eb6b0f91813906876b1f1e6fd6e5c59c41e Mon Sep 17 00:00:00 2001 From: Aaron Clarke Date: Fri, 9 Oct 2026 14:16:36 -0700 Subject: [PATCH 11/12] Update 210.0000-parallel-gles-linking.md --- rfc/210.0000-parallel-gles-linking.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/rfc/210.0000-parallel-gles-linking.md b/rfc/210.0000-parallel-gles-linking.md index 95d5a80..bc91f77 100644 --- a/rfc/210.0000-parallel-gles-linking.md +++ b/rfc/210.0000-parallel-gles-linking.md @@ -256,6 +256,11 @@ class PipelineQueue { } ``` +The LIMIT value will be informed by the number of cores avaiable to the machine. +The driver itself is managing its own thread pools and the LIMIT just controls +how much we make visible to the io thread in order to limit the latency when +performing a compilation eagerly. + ## Testing We already have the benefit of many high level integration tests. Since this From 99d6346c0b6468aaef66652cb8ad5c9b59a73745 Mon Sep 17 00:00:00 2001 From: flutteractionsbot Date: Fri, 9 Oct 2026 23:07:16 +0000 Subject: [PATCH 12/12] docs(rfc): assign RFC 210.0001 --- ...el-gles-linking.md => 210.0001-parallel-gles-linking.md} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename rfc/{210.0000-parallel-gles-linking.md => 210.0001-parallel-gles-linking.md} (98%) diff --git a/rfc/210.0000-parallel-gles-linking.md b/rfc/210.0001-parallel-gles-linking.md similarity index 98% rename from rfc/210.0000-parallel-gles-linking.md rename to rfc/210.0001-parallel-gles-linking.md index bc91f77..d87eb56 100644 --- a/rfc/210.0000-parallel-gles-linking.md +++ b/rfc/210.0001-parallel-gles-linking.md @@ -1,11 +1,11 @@ --- type: rfc -rfc: '210.0000' +rfc: '210.0001' title: Parallel OpenGLES Linking in Impeller description: Outlines how Impeller will implement parallel shader compilation with the OpenGLES backend. status: draft created: 2026-10-09T00:00:00Z -updated: 2026-10-09T00:00:00Z +updated: 2026-10-09T23:07:13.777951Z tags: - 210-graphics authors: @@ -13,7 +13,7 @@ authors: - https://github.com/walley892 --- -# RFC 210.0000: Parallel OpenGLES Linking in Impeller +# RFC 210.0001: Parallel OpenGLES Linking in Impeller ## Description