Intrepid/prometeu-runtime
Intrepid/prometeu-runtime
4
0
Fork 0
Code Pull Requests Activity

align render worker agenda direction

Browse Source
This commit is contained in:
bQUARKz 2026-06-15 12:15:57 +01:00
parent a761e73587
commit 373f842bef
Signed by: bquarkz
SSH Key Fingerprint: SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
1 changed files with 16 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md
View File

@ -167,9 +167,9 @@ O host desktop pode ser a primeira integracao concreta, mas nao deve ser o unico
**Pergunta:** Quem chama present: worker, host event loop, ou display cadence service?
**Sugestao:** no primeiro corte, o worker deve produzir/publish uma superficie pronta e notificar host invalidation; o host event loop continua sendo autoridade de apresentacao da janela nativa. O "repeat ultimo frame valido" deve ser modelado no controller/telemetry como comportamento de consumo/cadence, mas o swap/window present concreto deve respeitar o host.
**Sugestao:** no primeiro corte, o worker deve produzir/publish uma superficie pronta como buffer RGBA8888 owned, por exemplo `OwnedRgba8888Frame`. O host event loop continua sendo autoridade de apresentacao da janela nativa. O "repeat ultimo frame valido" deve repetir o ultimo buffer publicado, nao recompor nem exigir que o worker conheca a API nativa de janela/swap.
**Motivo:** winit/pixels e plataformas graficas frequentemente tem afinidade com thread/event loop. Colocar o swap real dentro do worker pode funcionar em alguns hosts e quebrar portabilidade. O contrato importante e que a VM nao bloqueie e que o host tenha uma superficie publicada coerente.
**Motivo:** RGBA8888 ja e o formato logico canonico nas specs. Um frame owned com `FrameId`, ownership/epoch, largura, altura, stride e pixels RGBA8888 deixa o contrato testavel sem janela e evita acoplamento a winit/pixels, SDL, swapchain ou textura nativa. Colocar o swap real dentro do worker pode funcionar em alguns hosts e quebrar portabilidade. O contrato importante e que a VM nao bloqueie e que o host tenha uma superficie publicada coerente.
### 5. Como o worker recebe recursos read-only?
@ -219,5 +219,19 @@ Esta agenda pode virar decision quando tivermos:
## Discussion
- 2026-06-06: Agenda criada dentro da `DSC-0042` para separar worker real da preparacao de fronteira discutida em `AGD-0042`.
- 2026-06-15: Apos a conclusao dos planos `PLN-0098` a `PLN-0109`, a direcao da agenda foi alinhada em torno da Opcao C: controller em `prometeu-system`, handoff single-slot thread-safe, backend fake/local primeiro, e publicacao de frame owned RGBA8888 antes da integracao desktop concreta.
## Resolution
Direcao proposta para decisao:
- `RenderManager` continua como autoridade de policy, ownership/epoch, latest-wins e telemetry;
- o worker controller contratual deve viver em `prometeu-system`;
- traits compartilhadas minimas podem viver em `prometeu-hal`;
- o handoff real deve ser single-slot latest-wins com sincronizacao explicita, inicialmente `Mutex<Option<RenderSubmission>> + Condvar`;
- o worker separa `pending` de `in_flight` e checa stop/ownership/epoch antes de publicar;
- o worker publica um `OwnedRgba8888Frame` ou equivalente, contendo frame id, owner/epoch, dimensoes, stride e pixels RGBA8888 owned;
- o host event loop faz o upload/present nativo a partir do ultimo frame publicado;
- o primeiro backend deve ser fake/local para provar contrato e concorrencia sem janela;
- a integracao desktop concreta vem depois, usando a mesma trait/backend contract;
- testes devem usar barreiras/condvars para provar ausencia de bloqueio da VM, latest-wins, stale discard, shutdown bounded e telemetry.