Repository navigation
ci: bump actions/upload-artifact from 4 to 7 - #4
Open
dependabot[bot] wants to merge 1 commit into
Open
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
dependabot
Bot
force-pushed
the
dependabot/github_actions/actions/upload-artifact-7
branch
from
June 2, 2026 00:48
521d189 to
5e4da9d
Compare
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 7. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v4...v7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/github_actions/actions/upload-artifact-7
branch
from
June 2, 2026 02:37
5e4da9d to
b03d570
Compare
Zerotwo63
pushed a commit
to Zerotwo63/melonx-performance
that referenced
this pull request
Oct 6, 2026
…co real AzureDominus#4) Objetivo: explicar por qué renderLoopEntered=true pero renderLoopIterations=0 pese a que JIT, Vulkan instance/device, Metal surface, swapchain, command buffer y el primer queueSubmit ya habían tenido éxito. Causa estructural confirmada leyendo el código (no supuesta): WindowBase.Render() corre en el hilo "GUI.RenderLoop", pero la closure que de verdad contiene el while(_isActive) (con WaitFifo/ProcessFrame/ ConsumeFrameAvailable/PresentFrame) NO corre en ese hilo - se pasa como "gpuLoop" a Device.Gpu.Renderer.RunLoop(), que es ThreadedRenderer.RunLoop(): crea un hilo NUEVO ("GPU.MainThread") para ejecutar esa closure, y el hilo que llamó a RunLoop() (GUI.RenderLoop) en vez de eso entra inmediatamente a su propio RenderLoop() - el consumidor de la cola de comandos GAL que reenvía cada llamada Pipeline/Window hecha desde GPU.MainThread al backend real (VulkanRenderer). "render loop entered" se logueaba en GUI.RenderLoop ANTES de llegar a RunLoop() - nunca probaba que GPU.MainThread realmente arrancara ni avanzara. Dos esperas bloqueantes reales (sin timeout) se ejecutan en GPU.MainThread ANTES de llegar al while(_isActive), y ninguna tenía instrumentación: 1. Device.Gpu.SetGpuThread() -> Renderer.GetCapabilities() en un ThreadedRenderer hace un round-trip por la cola de comandos GAL (InvokeCommand -> _invokeRun.Wait(), sin timeout) que depende de que el hilo GUI.RenderLoop ya esté corriendo su propio RenderLoop() consumidor. 2. Device.Gpu.InitializeShaderCache() -> HostInitalized.WaitOne() (un ManualResetEvent que arranca sin señalar) bloquea indefinidamente hasta que algo llame HostInitalized.Set() - solo ocurre hoy desde el flujo de carga del juego (ProcessLoader.cs/FileSystemExtensions.cs). Se instrumenta con logs antes/después cada wait/llamada bloqueante en esta región exacta: GpuContext.SetGpuThread/InitializeShaderCache, ThreadedRenderer.RunLoop/InvokeCommand, y dentro del while(_isActive) en WindowBase.cs: condición del loop, _isStopped, _pauseEvent.WaitOne, Device.WaitFifo, con un contador real de iteración (gated: todas las primeras 5 + cada 300) que alimenta renderLoopIterations/ lastRenderLoopStage de verdad por primera vez - antes ese campo no tenía ningún emisor real en C#, así que renderLoopIterations=0 no probaba un bloqueo, solo que nunca se implementó el contador. También se envuelve la llamada completa a RunLoop() (antes sin ningún try/catch) y el setup inicial de la closure en try/catch que reportan vía ReportBootFailure con tipo/mensaje/stack trace completo antes de relanzar - ninguna excepción en esta región puede perderse en silencio. Ningún comportamiento cambiado: mismas condiciones, mismo orden, solo instrumentación aditiva y una variable local (hasFifoCommands) para poder loguear antes/después del valor que ya se usaba inline. 2 tests nuevos verificando que los eventos de GPU.MainThread cuentan como progreso real del render loop y que renderLoopIterations solo avanza desde heartbeats reales, no desde "render loop entered".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps actions/upload-artifact from 4 to 7.
Release notes
Sourced from actions/upload-artifact's releases.
... (truncated)
Commits
043fb46Merge pull request #797 from actions/yacaovsnc/update-dependency634250cInclude changes in typespec/ts-http-runtime 0.3.5e454baaReadme: bump all the example versions to v7 (#796)74fad66Update the readme with direct upload details (#795)bbbca2dSupport direct file uploads (#764)589182cUpgrade the module to ESM and bump dependencies (#762)47309c9Merge pull request #754 from actions/Link-/add-proxy-integration-tests02a8460Add proxy integration testb7c566aMerge pull request #745 from actions/upload-artifact-v6-releasee516bc8docs: correct description of Node.js 24 support in README