ich würde gerne einen gitea runner für windows installieren und hier registrieren
soll auch der windows client für tests während dem entwickeln verwendet werden, damit der host hier entlastet wird
1. ich würde gerne einen gitea runner für windows installieren und hier registrieren
2. soll auch der windows client für tests während dem entwickeln verwendet werden, damit der host hier entlastet wird
Done in 857e23c, wiki 02ac5da. Both points of this issue are in place, one thing is still untested (see Open).
What you get
1. A Gitea runner on the Windows machine.melektaus-atx-wsl runs in the WSL2 distro game-maker-ci on melektaus-atx and takes the jobs of this repo. Both CI jobs now ask for its label game-maker-wsl, and ci.yml is enabled again.
The runner on stein2 stays as it is: registered, with its label game-maker-ci and the same image. It gets no game-maker jobs any more. Moving back is one line per job in ci.yml (runs-on: game-maker-ci).
2. Tests during development run there too. Gate, single e2e modules, the full suite and the smokes of a working tree now run on the Windows machine in the CI image, so stein2 only builds (the build is the deployment).
Everything about the machine is in D:\1\Development\gitea-runner\README.md: what lies where, how it starts, how to stop it, how to rebuild the image and how to set it up again.
Under the hood
The runner is gitea-runner 4.0.0 (linux-amd64, checksum verified). It is registered to this repo only, so no workflow of another repo runs on the PC.
Jobs run in Docker inside the distro, in the image game-maker-ci built from tools/ci/Dockerfile. The fonts are the same as on stein2.
The GPU: under WSL2 it is /dev/dxg behind Mesa's d3d12 driver. Headless chromium gets no WebGL there, so GAME_MAKER_BROWSER=wsl (set by the runner) starts an invisible Xvfb and an X11 chromium on ANGLE/GL. The job log shows renderer: ANGLE (Microsoft Corporation, D3D12 (NVIDIA GeForce RTX 4070), OpenGL 4.2). Without the variable, stein2 keeps its headless Vulkan launch.
Every run now names its renderer and stops on software rendering. Under WSL a missing driver does not fail by itself: llvmpipe still offers WebGL 2.
Start: the scheduled task game-maker-ci starts the distro 30 s after boot, without a logon (S4U, no stored password). systemd inside starts docker and the runner.
Limits:C:\Users\meleki\.wslconfig gives the WSL VM 4 cores and 16 GB, puts its swap on D: and keeps the distro from stopping when idle. This is the WSL VM of meleki only, Docker Desktop under MelekTaus is not touched.
Dead ends on the way: Vulkan through a self-built dzn (ANGLE stays at ES 2.0), and Wayland on weston (reaches the GPU, but the editor's clock stalled in long runs).
Tests
first CI run (run 224, 857e23c)
gate 195 files, 2823 tests, CHECK EXIT 0; PHP 53 / 15 / 20 3:18
suite 1589 of 1590 checks, the one FAIL is e2e 41 (#282) e2e 13:34
development runs on the machine
check 195 files, 2823 tests, CHECK EXIT 0 131 s
39,40 ALL PASSED - 100 checks 78 s (with npm ci)
smokes 24 / 19 / 21 checks 69 s
stein2 headless, e2e 39+40 with the new harness: ALL PASSED - 100 checks
The runner stays online with no session open (checked for over two minutes). After wsl --terminate it stays off until the task starts again; Start-ScheduledTask game-maker-ci brings it back online in 13 s.
The suite takes about 40% longer than on stein2, almost all of it in modules that read back many pixels (drawing, tilemaps, shaders).
1590 is now a measured count, not a calculated one.
Open
A real reboot of Windows is not tested. The start at boot is set up, but I did not restart your PC. After the next reboot, wsl -l -v should show game-maker-ci as Running, and the runner should be online in the repo's runner list.
#282 makes this runner red about every other run. e2e 41 failed in the first CI run and in two of three solo runs. That is the next issue.
Done in `857e23c`, wiki `02ac5da`. Both points of this issue are in place, one thing is still untested (see *Open*).
**What you get**
- **1. A Gitea runner on the Windows machine.** `melektaus-atx-wsl` runs in the WSL2 distro `game-maker-ci` on melektaus-atx and takes the jobs of this repo. Both CI jobs now ask for its label `game-maker-wsl`, and `ci.yml` is enabled again.
- **The runner on stein2 stays as it is:** registered, with its label `game-maker-ci` and the same image. It gets no game-maker jobs any more. Moving back is one line per job in `ci.yml` (`runs-on: game-maker-ci`).
- **2. Tests during development run there too.** Gate, single e2e modules, the full suite and the smokes of a working tree now run on the Windows machine in the CI image, so stein2 only builds (the build is the deployment).
- Everything about the machine is in `D:\1\Development\gitea-runner\README.md`: what lies where, how it starts, how to stop it, how to rebuild the image and how to set it up again.
**Under the hood**
- The runner is gitea-runner 4.0.0 (linux-amd64, checksum verified). It is registered **to this repo only**, so no workflow of another repo runs on the PC.
- Jobs run in Docker inside the distro, in the image `game-maker-ci` built from `tools/ci/Dockerfile`. The fonts are the same as on stein2.
- **The GPU:** under WSL2 it is `/dev/dxg` behind Mesa's d3d12 driver. Headless chromium gets no WebGL there, so `GAME_MAKER_BROWSER=wsl` (set by the runner) starts an invisible Xvfb and an X11 chromium on ANGLE/GL. The job log shows `renderer: ANGLE (Microsoft Corporation, D3D12 (NVIDIA GeForce RTX 4070), OpenGL 4.2)`. Without the variable, stein2 keeps its headless Vulkan launch.
- **Every run now names its renderer and stops on software rendering.** Under WSL a missing driver does not fail by itself: llvmpipe still offers WebGL 2.
- **Start:** the scheduled task `game-maker-ci` starts the distro 30 s after boot, without a logon (S4U, no stored password). systemd inside starts docker and the runner.
- **Limits:** `C:\Users\meleki\.wslconfig` gives the WSL VM 4 cores and 16 GB, puts its swap on `D:` and keeps the distro from stopping when idle. This is the WSL VM of `meleki` only, Docker Desktop under `MelekTaus` is not touched.
- Dead ends on the way: Vulkan through a self-built `dzn` (ANGLE stays at ES 2.0), and Wayland on weston (reaches the GPU, but the editor's clock stalled in long runs).
**Tests**
```
first CI run (run 224, 857e23c)
gate 195 files, 2823 tests, CHECK EXIT 0; PHP 53 / 15 / 20 3:18
suite 1589 of 1590 checks, the one FAIL is e2e 41 (#282) e2e 13:34
development runs on the machine
check 195 files, 2823 tests, CHECK EXIT 0 131 s
39,40 ALL PASSED - 100 checks 78 s (with npm ci)
smokes 24 / 19 / 21 checks 69 s
stein2 headless, e2e 39+40 with the new harness: ALL PASSED - 100 checks
```
- The runner stays online with no session open (checked for over two minutes). After `wsl --terminate` it stays off until the task starts again; `Start-ScheduledTask game-maker-ci` brings it back online in 13 s.
- The suite takes about 40% longer than on stein2, almost all of it in modules that read back many pixels (drawing, tilemaps, shaders).
- **1590 is now a measured count**, not a calculated one.
**Open**
- **A real reboot of Windows is not tested.** The start at boot is set up, but I did not restart your PC. After the next reboot, `wsl -l -v` should show `game-maker-ci` as Running, and the runner should be online in the repo's runner list.
- **#282 makes this runner red about every other run.** e2e 41 failed in the first CI run and in two of three solo runs. That is the next issue.
Follow-up in ffedd81, wiki 8a37cc4: the suite was slower on the RTX than on stein2.
What you get
The six modules that read many pixels now take 32 s instead of 139 s on the Windows runner, faster than on stein2.
module
before, WSL
now, WSL
stein2
04 assets
25.9 s
9.3 s
12.8 s
05 drawing
59.3 s
3.9 s
9.9 s
30 font
16.2 s
5.5 s
7.4 s
37 nineSlice
22.7 s
8.9 s
11.2 s
44 documents
5.0 s
1.2 s
1.9 s
58 clipAreas
9.9 s
2.8 s
4.5 s
Under the hood
Cause: every __gm.pixelAt rendered the whole stage into a fresh texture and waited for the GPU to hand back one pixel. That costs ~7 ms under WSL and ~2 ms on stein2. pixelRow and several checks read hundreds of pixels this way. Module 05 spent 36.8 of its 40 s on it.
Fix:stagePixels in src/ui/render.ts renders once around all points and reads them in one go. The hook __gm.pixels(points) exposes it. pixelRow uses it, and the loops in e2e 04, 05, 14 and 44 read in one call.
The colours are identical: checked at 10 680 points on the RTX (d3d12) and on stein2 (Intel/Vulkan). The old comment claiming that a wider read comes back wrong was not true and is gone.
What stays: frames with real work are still longer under WSL (e2e 40 waits 50 ms for two frames, stein2 33 ms). perf puts three quarters of chromium's GPU process in the drivers (NVIDIA D3D12 31%, Mesa d3d12 23%, kernel/dxg 19%). That is the price of OpenGL over d3d12, not the hardware. Four browser and Mesa switches were measured on e2e 39/40, none helped. Details are on Development.
Tests
gate (melektaus-atx) 195 files, 2827 tests, CHECK EXIT 0 (+4 for stagePixels)
e2e 1-16,30,37,44,58 (WSL) ALL PASSED - 587 checks
same colours, RTX and stein2 diff=0 at 10 680 points each
Counter-check: with a wrong index the first stagePixels unit test fails.
The saving on the full suite is not measured yet. The CI run for 9cff528 shows it.
Closing. The runner, the development runs and the speed-up are in place, and #282 is fixed in 9cff528. Still untested: a real reboot of Windows. The last boot was at 15:53, before the scheduled task existed. After the next reboot, wsl -l -v should show game-maker-ci as Running and the runner should be online in the repo's runner list. If not, reopen this issue.
Follow-up in `ffedd81`, wiki `8a37cc4`: the suite was slower on the RTX than on stein2.
**What you get**
- The six modules that read many pixels now take **32 s instead of 139 s** on the Windows runner, faster than on stein2.
| module | before, WSL | now, WSL | stein2 |
|---|---|---|---|
| 04 assets | 25.9 s | 9.3 s | 12.8 s |
| 05 drawing | 59.3 s | 3.9 s | 9.9 s |
| 30 font | 16.2 s | 5.5 s | 7.4 s |
| 37 nineSlice | 22.7 s | 8.9 s | 11.2 s |
| 44 documents | 5.0 s | 1.2 s | 1.9 s |
| 58 clipAreas | 9.9 s | 2.8 s | 4.5 s |
**Under the hood**
- **Cause:** every `__gm.pixelAt` rendered the whole stage into a fresh texture and waited for the GPU to hand back one pixel. That costs ~7 ms under WSL and ~2 ms on stein2. `pixelRow` and several checks read hundreds of pixels this way. Module 05 spent 36.8 of its 40 s on it.
- **Fix:** `stagePixels` in `src/ui/render.ts` renders once around all points and reads them in one go. The hook `__gm.pixels(points)` exposes it. `pixelRow` uses it, and the loops in e2e 04, 05, 14 and 44 read in one call.
- The colours are identical: checked at 10 680 points on the RTX (d3d12) and on stein2 (Intel/Vulkan). The old comment claiming that a wider read comes back wrong was not true and is gone.
- **What stays:** frames with real work are still longer under WSL (e2e 40 waits 50 ms for two frames, stein2 33 ms). `perf` puts three quarters of chromium's GPU process in the drivers (NVIDIA D3D12 31%, Mesa d3d12 23%, kernel/dxg 19%). That is the price of OpenGL over d3d12, not the hardware. Four browser and Mesa switches were measured on e2e 39/40, none helped. Details are on *Development*.
**Tests**
```
gate (melektaus-atx) 195 files, 2827 tests, CHECK EXIT 0 (+4 for stagePixels)
e2e 1-16,30,37,44,58 (WSL) ALL PASSED - 587 checks
same colours, RTX and stein2 diff=0 at 10 680 points each
```
- Counter-check: with a wrong index the first `stagePixels` unit test fails.
- The saving on the full suite is not measured yet. The CI run for `9cff528` shows it.
**Closing.** The runner, the development runs and the speed-up are in place, and #282 is fixed in `9cff528`. Still **untested: a real reboot of Windows.** The last boot was at 15:53, before the scheduled task existed. After the next reboot, `wsl -l -v` should show `game-maker-ci` as Running and the runner should be online in the repo's runner list. If not, reopen this issue.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Done in
857e23c, wiki02ac5da. Both points of this issue are in place, one thing is still untested (see Open).What you get
melektaus-atx-wslruns in the WSL2 distrogame-maker-cion melektaus-atx and takes the jobs of this repo. Both CI jobs now ask for its labelgame-maker-wsl, andci.ymlis enabled again.game-maker-ciand the same image. It gets no game-maker jobs any more. Moving back is one line per job inci.yml(runs-on: game-maker-ci).D:\1\Development\gitea-runner\README.md: what lies where, how it starts, how to stop it, how to rebuild the image and how to set it up again.Under the hood
game-maker-cibuilt fromtools/ci/Dockerfile. The fonts are the same as on stein2./dev/dxgbehind Mesa's d3d12 driver. Headless chromium gets no WebGL there, soGAME_MAKER_BROWSER=wsl(set by the runner) starts an invisible Xvfb and an X11 chromium on ANGLE/GL. The job log showsrenderer: ANGLE (Microsoft Corporation, D3D12 (NVIDIA GeForce RTX 4070), OpenGL 4.2). Without the variable, stein2 keeps its headless Vulkan launch.game-maker-cistarts the distro 30 s after boot, without a logon (S4U, no stored password). systemd inside starts docker and the runner.C:\Users\meleki\.wslconfiggives the WSL VM 4 cores and 16 GB, puts its swap onD:and keeps the distro from stopping when idle. This is the WSL VM ofmelekionly, Docker Desktop underMelekTausis not touched.dzn(ANGLE stays at ES 2.0), and Wayland on weston (reaches the GPU, but the editor's clock stalled in long runs).Tests
wsl --terminateit stays off until the task starts again;Start-ScheduledTask game-maker-cibrings it back online in 13 s.Open
wsl -l -vshould showgame-maker-cias Running, and the runner should be online in the repo's runner list.Follow-up in
ffedd81, wiki8a37cc4: the suite was slower on the RTX than on stein2.What you get
Under the hood
__gm.pixelAtrendered the whole stage into a fresh texture and waited for the GPU to hand back one pixel. That costs ~7 ms under WSL and ~2 ms on stein2.pixelRowand several checks read hundreds of pixels this way. Module 05 spent 36.8 of its 40 s on it.stagePixelsinsrc/ui/render.tsrenders once around all points and reads them in one go. The hook__gm.pixels(points)exposes it.pixelRowuses it, and the loops in e2e 04, 05, 14 and 44 read in one call.perfputs three quarters of chromium's GPU process in the drivers (NVIDIA D3D12 31%, Mesa d3d12 23%, kernel/dxg 19%). That is the price of OpenGL over d3d12, not the hardware. Four browser and Mesa switches were measured on e2e 39/40, none helped. Details are on Development.Tests
stagePixelsunit test fails.9cff528shows it.Closing. The runner, the development runs and the speed-up are in place, and #282 is fixed in
9cff528. Still untested: a real reboot of Windows. The last boot was at 15:53, before the scheduled task existed. After the next reboot,wsl -l -vshould showgame-maker-cias Running and the runner should be online in the repo's runner list. If not, reopen this issue.