From 1022750c12c689f0e037624d7e0c26677cd4826f Mon Sep 17 00:00:00 2001 From: bQUARKz Date: Mon, 15 Jun 2026 12:28:25 +0100 Subject: [PATCH] resolve render worker agenda questions --- ...D-0043-real-render-worker-establishment.md | 20 +++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md b/discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md index af4d6edd..122fc8eb 100644 --- a/discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md +++ b/discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md @@ -159,7 +159,7 @@ O host desktop pode ser a primeira integracao concreta, mas nao deve ser o unico **Pergunta:** Como modelar current work para shutdown e stale owner? -**Sugestao:** separar `pending` de `in_flight`. Ao tomar uma submission, o worker carimba `in_flight` localmente, renderiza, e checa ownership/epoch contra um snapshot atomico ou handle compartilhado antes de present. Shutdown sinaliza stop, acorda o worker e faz join bounded; se houver trabalho em andamento, ele pode terminar rasterizacao, mas nao pode apresentar se o owner/epoch estiver obsoleto ou o stop ja exigir descarte. +**Sugestao:** separar `pending` de `in_flight`. Ao tomar uma submission, o worker carimba `in_flight` localmente, renderiza, e checa ownership/epoch contra um snapshot atomico ou handle compartilhado antes de present. Shutdown sinaliza stop, acorda o worker e faz join bounded; se houver trabalho em andamento, ele pode terminar rasterizacao, mas nao pode apresentar se o owner/epoch estiver obsoleto ou o stop ja exigir descarte. O timeout deve ser configuravel; como default inicial, usar `250ms`, que e longo o bastante para evitar falso positivo em desktop comum e curto o bastante para detectar worker preso sem travar encerramento. **Motivo:** isso evita que shutdown dependa de cancelar mid-raster em codigo que talvez nao seja cancelavel, mas ainda impede present obsoleto. @@ -167,17 +167,17 @@ 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 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. +**Sugestao:** no primeiro corte, o worker deve produzir/publish uma superficie pronta como buffer RGBA8888 owned, por exemplo `OwnedRgba8888Frame`, definido em `prometeu-hal`. 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:** 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. +**Motivo:** RGBA8888 ja e o formato logico canonico nas specs. Um frame owned com `FrameId`, ownership/epoch, largura, altura, `stride_pixels` e pixels RGBA8888 em `Vec` 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? **Pergunta:** Como o worker recebe recursos read-only preparados na `AGD-0042`? -**Sugestao:** o primeiro backend deve receber `RenderSubmission` owned e handles/read-only resource accessors necessarios para resolver glyph/scene banks. Esses accessors devem ser compartilhaveis e imutaveis durante o consumo, evitando `&mut Hardware`, `&mut Gfx` e `FrameComposer` vivo. +**Sugestao:** o primeiro backend deve receber `RenderSubmission` owned e uma interface compacta de acesso read-only aos banks por id. Banks sao read-only por definicao durante o consumo de render; o worker resolve recursos por ids estaveis, sem copiar bank, sem snapshot de bank e sem depender de `Arc` como requisito do contrato. -**Motivo:** `AGD-0042` eliminou o bridge monolitico exatamente para impedir que o worker dependa do hardware inteiro. A proxima decisao precisa declarar quais recursos sao lidos pelo render backend e como sua estabilidade e garantida durante uma submissao em voo. +**Motivo:** `AGD-0042` eliminou o bridge monolitico exatamente para impedir que o worker dependa do hardware inteiro. A proxima decisao precisa declarar quais recursos sao lidos pelo render backend e como sua estabilidade e garantida durante uma submissao em voo. A estabilidade vem da regra de leitura: o worker ve banks por id via interface read-only, enquanto instalacao/mutacao de bank permanece fora do consumo renderizavel em voo. ### 6. Qual erro tipado minimo? @@ -199,9 +199,9 @@ O host desktop pode ser a primeira integracao concreta, mas nao deve ser o unico **Pergunta:** Qual sera o primeiro backend real: desktop `Gfx`/pixels, framebuffer local, ou fake backend? -**Sugestao:** implementar primeiro um backend fake/mocked para contrato e um backend local framebuffer para integracao sem janela. A integracao desktop deve vir em seguida como consumidor concreto, usando a mesma trait. +**Sugestao:** implementar primeiro um backend fake/mocked para contrato e um backend local framebuffer para integracao sem janela. A integracao desktop vem em seguida como consumidor concreto, usando a mesma trait. Ao final desta agenda, o worker deve estar funcionando completamente no caminho host real; a divisao em planos serve para controlar risco, nao para reduzir o alvo final. -**Motivo:** se o primeiro backend for desktop/winit, o contrato corre risco de nascer acoplado a detalhes de janela. Se o primeiro for fake/local, a semantica do worker fica testavel antes da integracao visual. +**Motivo:** se o primeiro backend for desktop/winit, o contrato corre risco de nascer acoplado a detalhes de janela. Se o primeiro for fake/local, a semantica do worker fica testavel antes da integracao visual. Ainda assim, a agenda so deve ser considerada concluida quando a integracao host real tambem estiver operando sobre o worker. ## Criterio para Encerrar @@ -220,6 +220,7 @@ Esta agenda pode virar decision quando tivermos: - 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. +- 2026-06-15: Perguntas restantes alinhadas: `OwnedRgba8888Frame` deve viver em `prometeu-hal` com pixels `Vec` RGBA8888; banks sao acessados por interface compacta read-only via ids, sem copia/snapshot/`Arc` como contrato; shutdown deve ter timeout configuravel com default inicial sugerido de `250ms`; a agenda pode virar varios plans, mas so fecha quando o worker funcionar no host real. ## Resolution @@ -230,8 +231,11 @@ Direcao proposta para decisao: - traits compartilhadas minimas podem viver em `prometeu-hal`; - o handoff real deve ser single-slot latest-wins com sincronizacao explicita, inicialmente `Mutex> + 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; +- shutdown deve ser bounded e configuravel; default inicial sugerido: `250ms`; +- o worker publica um `OwnedRgba8888Frame` em `prometeu-hal`, contendo frame id, owner/epoch, dimensoes, `stride_pixels` e pixels RGBA8888 owned em `Vec`; +- o worker acessa banks por ids estaveis atraves de uma interface compacta read-only; nao copia banks, nao depende de snapshots de bank e nao usa `Arc` como parte obrigatoria do contrato; - 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; +- a agenda pode ser executada em varios plans, mas o criterio final e ter o worker funcionando completamente no host real; - testes devem usar barreiras/condvars para provar ausencia de bloqueio da VM, latest-wins, stale discard, shutdown bounded e telemetry.