Today I Learned

Ubuntu 24.04 upgrade broke my GNOME desktop (ROCm leftovers)

2026-01-13T00:00:00+00:00

I finally upgraded my Ubuntu 22.04 machine to 24.04. The upgrade itself went smoothly, but rebooting into the new system greeted me with GNOME's dreaded crash screen—the white "X_X" face with "Oh no! Something has gone wrong."</p>

The culprit? Old ROCm 6.4.3 artifacts from the previous installation were incompatible with 24.04's stricter parsing and newer libraries.</p> </span>

The symptoms</h2>
After rebooting, I couldn't even get to a TTY login prompt initially. The system would boot, show the crash screen, and that was it. Recovery mode was the only way in.</p>

Issues I encountered</h2>

1. PostgreSQL blocking the upgrade</h3>

Before I could even start the upgrade, do-release-upgrade</code> complained about PostgreSQL packages being in the removal deny list. Had to purge them first:</p>

sudo</span> apt purge postgresql</span>*</span></span></code></pre>2. Invalid udev rule syntax</h3>
Ubuntu 24.04 has stricter udev parsing. The ROCm rule at /etc/udev/rules.d/70-amdgpu.rules</code> had swapped operators:</p>
# Broken (22.04 tolerated this)</span></span>
KERNEL</span>=</span>"kfd",</span> GROUP</span>=</span>="video",</span> MODE</span>=</span>"660"</span></span>
</span>
# Fixed (24.04 requires correct operators)</span></span>
KERNEL</span>=</span>="kfd",</span> GROUP</span>=</span>"video",</span> MODE</span>=</span>"0660"</span></span></code></pre>
The KERNEL</code> field needs ==</code> (comparison), while GROUP</code> needs =</code> (assignment). This one showed up in journalctl</code> as "Invalid operator for GROUP."</p>
3. Missing drmModeCloseFB</code> symbol</h3>
GNOME Shell was crashing with:</p>
/usr/bin/gnome-shell: symbol lookup error: /lib/x86_64-linux-gnu/libmutter-14.so.0: undefined symbol: drmModeCloseFB</span></span></code></pre>
The symbol existed in the system libdrm, but ROCm's old libdrm in /opt/amdgpu/lib/</code> was being loaded first due to leftover ld.so.conf.d</code> entries. The system was loading the wrong library.</p>
4. Xorg segfault</h3>
Even after fixing the libdrm issue, X11 wouldn't start—Xorg was segfaulting in radeonsi_dri.so</code>. Turned out there was an old /etc/X11/xorg.conf</code> from the amdgpu-pro days that was forcing incompatible settings.</p>
The fix</h2>
All of these issues traced back to leftover ROCm configuration files. The solution was to back them up and let the system use its defaults:</p>
# Back up the problematic ld.so.conf files</span></span>
sudo</span> mv /etc/ld.so.conf.d/15-amdgpu-pro.conf{,.bak}</span></span>
sudo</span> mv /etc/ld.so.conf.d/20-amdgpu.conf{,.bak}</span></span>
sudo</span> mv /etc/ld.so.conf.d/10-rocm-opencl.conf{,.bak}</span></span>
sudo</span> mv /etc/ld.so.conf.d/rocm.conf{,.bak}</span></span>
</span>
# Back up the old xorg.conf</span></span>
sudo</span> mv /etc/X11/xorg.conf{,.bak}</span></span>
</span>
# Rebuild the library cache</span></span>
sudo</span> ldconfig</span></span></code></pre>
After this, Wayland worked fine. I later reinstalled ROCm for noble</code> and everything came back up—PyTorch detects the GPU, compute workloads run, and the desktop is stable.</p>
What to preserve during upgrade</h2>
These config files should survive the upgrade intact:</p>

/etc/default/grub</code> — kept my RDNA3 stability params (amdgpu.gfxoff=0</code>, amdgpu.tmz=0</code>, amdgpu.runpm=0</code>, amdgpu.ppfeaturemask=0xfffd7fff</code>)</li>
/etc/security/limits.conf</code> — custom resource limits for GPU workloads</li>
</ul>
The upgrade process asked about these and I chose to keep my versions.</p>
Lesson learned</h2>
If you're upgrading from 22.04 with ROCm installed, expect breakage. The third-party repos get disabled automatically by do-release-upgrade</code>, but the old libraries and config files stick around and cause conflicts with the newer system components.</p>
My approach next time: completely purge ROCm before upgrading, then reinstall fresh for the new release. Would've saved me a few hours of debugging in recovery mode.</p>



CPU to GPU Particle Migration in Bevy: The Billboard Illusion
2025-12-24T00:00:00+00:00
The Problem</h2>
Ground explosions in my RTS game were killing performance. Each explosion spawned 150-280 ECS entities - individual particles for sparks, flash sparks, debris, dirt, smoke, and more. During artillery barrages with 6-10 simultaneous explosions, FPS tanked from 100 to 40.</p>
The CPU particle system was nice and simple where each particle was a Bevy entity with a mesh, material, and transform. But when I spawn them multiple times to create a barrage effect, it was crushing the FPS.</p>
So I decided to migrate to bevy_hanabi GPU particles. The idea is simple: instead of spawning hundreds of CPU entities, you get a single draw call per emitter type. Should be straightforward, right?</p>
The Easy Wins</h2>
The first emitters migrated relatively smoothly. Sparks, flash sparks, and parts debris went from ~100-185 entities down to 3 GPU effects. Some gotchas along the way:</p>
Additive blending is non-negotiable.</strong> GPU sparks showed dark/brown backgrounds instead of glowing. bevy_hanabi defaults to AlphaMode::Blend</code>, but sparks need AlphaMode::Add</code>.</p>
Watch for hidden brightness multipliers.</strong> GPU particles appeared orange-red instead of hot yellow-white. Turns out my CPU shader had a 4x brightness multiplier that I'd completely forgotten about. GPU gradients need the final rendered values directly.</p>
Velocity axis conventions differ.</strong> bevy_hanabi's AlongVelocity</code> mode uses X axis along velocity, while my CPU VelocityAligned</code> used Y axis. Swap your size gradient axes.</p>
Drag ≠ deceleration.</strong> LinearDragModifier</code> applies velocity-proportional drag (exponential decay). My CPU used constant deceleration. Replaced drag with AccelModifier</code> to match the original behavior.</p>
The Main Emitter Nightmare</h2>
Then I got to the main emitters that spawn directional blasts from the explosion. What started as "should be straightforward" became 8 devlogs and eventually required forking bevy_hanabi.</p>
The Mirroring Mystery</h3>
The core symptom was that particles appeared to travel "inward toward center then fly out the other side" - visually mirrored. I spent days investigating:</p>

Cross product sign flips in orientation math</li>
Quaternion vs axis-based rotation differences</li>
Camera-space vs world-space coordinate systems</li>
bevy_hanabi's AlongVelocity</code> implementation details</li>
</ul>
I tried at least 9 different approaches to fix the orientation: Gram-Schmidt orthogonalization, world-up reference vectors, quaternion-based rotation, camera-right projection... all failed. The mirroring persisted no matter what I tried.</p>
The Debug Breakthrough</h3>
After days of frustration, I spawned small colored quads (R=+X velocity, G=+Y, B=+Z) instead of large blasts with UV zoom to visualize actual particle velocities (which I should have done way earlier).</p>
The velocities were correct the whole time.</strong></p>
Particles clearly moved outward and the motion was 100% correct.</p>
The Actual Problem: A Visual Illusion</h3>
The "mirroring" was a perceptual illusion caused by the intense UV zoom effect. The main emitters use a 500x→1x UV zoom over their lifetime to create the "debris burst expanding from impact point" look.</p>
Here's the math: with UV scale starting at 500x, the visible texture region at t=0 is ~0.016m (tiny center point). At t=1, it's 20m (full blast). That's an apparent expansion rate of ~13 m/s radially outward from texture center.</p>
Meanwhile, actual particle velocity was only 3-5 m/s. The UV zoom's apparent motion completely dominated, and because it expanded from center (not bottom-pivot like CPU), it created the illusion of incorrect movement direction.</p>
The Actual Fixes</h2>
Once I understood what was really happening, the fixes were straightforward:</p>
Fix 1: UVScaleOverLifetimeModifier Bug</h3>
My custom modifier had inverted math:</p>
// WRONG: multiplying sends UVs out of bounds</span></span>
let</span> uv_scaled</span> =</span> uv_centered</span> *</span> uv_scale</span> +</span> vec2</span>(</span>0.5</span>,</span> 0.5</span>);</span></span>
// With scale=500: UV 0.0 becomes -249.5 (samples edge/garbage)</span></span>
</span>
// CORRECT: dividing zooms IN on center  </span></span>
let</span> uv_scaled</span> =</span> uv_centered</span> /</span> uv_scale</span> +</span> vec2</span>(</span>0.5</span>,</span> 0.5</span>);</span></span>
// With scale=500: UV 0.0 becomes 0.499 (samples center)</span></span></code></pre>
This was sampling edge pixels (solid color) instead of zooming in on the center.</p>
Fix 2: UV Pivot</h3>
CPU main emitters use bottom-pivot - the UV zoom expands upward along velocity. My GPU zoom expanded from center, fighting the particle motion. Added configurable pivot to the modifier.</p>
Fix 3: SimulationSpace::Local</h3>
bevy_hanabi defaults to SimulationSpace::Global</code>, which ignores Transform.scale</code>. CPU velocity was scaled, GPU was fixed. Switched to SimulationSpace::Local</code>.</p>
Fix 4: Expression Re-evaluation</h3>
bevy_hanabi's ExprWriter</code> re-evaluates rand()</code> calls on every expression use. Cloning an expression doesn't preserve computed values:</p>
let</span> dir</span> =</span> rx</span>.</span>vec3</span>(ry, rz)</span>.</span>normalized</span>();</span>  // Uses rand()</span></span>
let</span> pos</span> =</span> dir</span>.</span>clone</span>()</span> *</span> radius;</span>          // NEW random values!</span></span>
let</span> vel</span> =</span> dir</span>.</span>clone</span>()</span> *</span> speed;</span>           // DIFFERENT random values!</span></span>
// Result: pos and vel point in completely different directions</span></span></code></pre>
Fixed by reading the POSITION attribute after it's set:</p>
let</span> fb_pos</span> =</span> rx</span>.</span>vec3</span>(ry, rz)</span>.</span>normalized</span>()</span> *</span> radius;</span></span>
let</span> init_pos</span> =</span> SetAttributeModifier</span>::</span>new</span>(</span>Attribute</span>::</span>POSITION</span>, fb_pos</span>.</span>expr</span>());</span></span>
</span>
let</span> pos_read</span> =</span> writer</span>.</span>attr</span>(</span>Attribute</span>::</span>POSITION</span>);</span>  // Read back!</span></span>
let</span> velocity</span> =</span> pos_read</span>.</span>normalized</span>()</span> *</span> speed;</span></span></code></pre>The Cleanup</h2>
After that ordeal, the remaining emitters (dust ring, smoke cloud, wisp puffs) were refreshingly straightforward. A few notes:</p>

For FaceCameraPosition</code> orientation, use .with_rotation()</code> not .with_axis_rotation()</code> for random sprite rotation</li>
Flipbook animation requires updating SPRITE_INDEX</code> in the update phase, not just init</li>
Non-uniform X/Y scaling works with SizeOverLifetimeModifier</code> using Gradient<Vec3></code></li>
</ul>
Results</h2>
Emitter</th> CPU Entities</th> GPU Entities</th></tr></thead>

Main Blast</td> 9-17</td> 1</td></tr>
Secondary Blast</td> 7-13</td> 1</td></tr>
Sparks</td> 30-60</td> 1</td></tr>
Flash Sparks</td> 20-50</td> 1</td></tr>
Parts Debris</td> 50-75</td> 1</td></tr>
Dirt Debris</td> ~35</td> 1</td></tr>
Velocity Dirt</td> 10-15</td> 1</td></tr>
Dust Ring</td> 2-3</td> 1</td></tr>
Smoke Cloud</td> 10-15</td> 1</td></tr>
Wisp Puffs</td> 3</td> 1</td></tr>
</tbody></table>
Total reduction</strong>: ~170-290 entities → ~10 entities per explosion (95% reduction)</p>
Performance</strong>: 8-shell barrages now maintain 80+ FPS instead of dropping to 40.</p>
Key Takeaways</h2>


Debug with simple visuals first.</strong> Small colored quads revealed correct velocity when complex effects created illusions.</p>
</li>

UV zoom can overwhelm particle motion.</strong> 500x zoom creates ~13 m/s apparent motion that drowns out 3-5 m/s actual velocity.</p>
</li>

UV zoom math is counterintuitive.</strong> Divide to zoom in, multiply to zoom out.</p>
</li>

Expression cloning re-evaluates.</strong> Use attr()</code> to read back computed values in bevy_hanabi.</p>
</li>

SimulationSpace affects scale.</strong> Global ignores transform scale, Local applies it.</p>
</li>

Sometimes you need to fork.</strong> Complex VFX may require engine modifications.</p>
</li>
</ol>
The whole migration took about 9 days, with ~60% spent on the main emitters orientation/velocity issues that turned out to be mostly a visual illusion. Was it worth it? The 95% entity reduction and stable 80+ FPS during barrages say yes. But I learned a lesson to actually think with my brain during debugging rather than cursing at Claude.</p>


AMD GPU Stability
2025-12-14T00:00:00+00:00
I've been encountering more freezes and crashes with my AMD GPU lately. This has been the case since I started using it on Ubuntu 22.04, but it's happening more often now as I run longer RL training sessions. Crashes occur after 1-2 hours</strong> of compute workload (sometimes up to 26 hours)</p>
I see logs like this with sudo dmesg -w | grep -i amdgpu</code>:</p>

log</summary>
[45766.649450] amdgpu 0000:2f:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000</span></span>
[45766.649454] amdgpu 0000:2f:00.0: amdgpu:      Faulty UTCL2 client ID: CB/DB (</span>0x0</span>)</span></span>
[45766.649458] amdgpu 0000:2f:00.0: amdgpu:      MORE_FAULTS: 0x0</span></span>
[45766.649462] amdgpu 0000:2f:00.0: amdgpu:      WALKER_ERROR: 0x0</span></span>
[45766.649465] amdgpu 0000:2f:00.0: amdgpu:      PERMISSION_FAULTS: 0x0</span></span>
[45766.649469] amdgpu 0000:2f:00.0: amdgpu:      MAPPING_ERROR: 0x0</span></span>
[45766.649473] amdgpu 0000:2f:00.0: amdgpu:      RW: 0x0</span></span>
[45766.649480] amdgpu 0000:2f:00.0: amdgpu: [gfxhub] page fault (</span>src_id:0</span> ring:169 vmid:0 pasid:0, for process  pid</span> 0</span> thread  pid</span> 0</span>)</span></span>
[45766.649486] amdgpu 0000:2f:00.0: amdgpu:   in page starting at address 0x0000000000000000 from client 10</span></span>
[45766.649491] amdgpu 0000:2f:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000</span></span>
[45766.649494] amdgpu 0000:2f:00.0: amdgpu:      Faulty UTCL2 client ID: CB/DB (</span>0x0</span>)</span></span>
[45766.649499] amdgpu 0000:2f:00.0: amdgpu:      MORE_FAULTS: 0x0</span></span>
[45766.649502] amdgpu 0000:2f:00.0: amdgpu:      WALKER_ERROR: 0x0</span></span>
[45766.649506] amdgpu 0000:2f:00.0: amdgpu:      PERMISSION_FAULTS: 0x0</span></span>
[45766.649510] amdgpu 0000:2f:00.0: amdgpu:      MAPPING_ERROR: 0x0</span></span>
[45766.649513] amdgpu 0000:2f:00.0: amdgpu:      RW: 0x0</span></span>
[45767.021585] amdgpu 0000:2f:00.0: amdgpu: soft reset failed, will fallback to full reset</span>!</span></span>
[45767.270210] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *ERROR*</span> MES failed to response msg=</span>3</span></span>
[45767.270475] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45767.393294] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *</span>ERROR</span>*</span> MES failed to response msg</span>=</span>3</span></span>
[45767.393507] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45767.516446] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *</span>ERROR</span>*</span> MES failed to response msg</span>=</span>3</span></span>
[45767.516671] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45767.639817] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *</span>ERROR</span>*</span> MES failed to response msg</span>=</span>3</span></span>
[45767.640034] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45767.762951] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *</span>ERROR</span>*</span> MES failed to response msg</span>=</span>3</span></span>
[45767.763170] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45767.886107] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *</span>ERROR</span>*</span> MES failed to response msg</span>=</span>3</span></span>
[45767.886325] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45768.009310] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *</span>ERROR</span>*</span> MES failed to response msg</span>=</span>3</span></span>
[45768.009532] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45768.132480] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *</span>ERROR</span>*</span> MES failed to response msg</span>=</span>3</span></span>
[45768.132719] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45768.255533] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]]</span> *</span>ERROR</span>*</span> MES failed to response msg</span>=</span>3</span></span>
[45768.255760] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]</span> *</span>ERROR</span>*</span> failed to unmap legacy queue</span></span>
[45768.522784] [drm:gfx_v11_0_cp_gfx_enable.isra.0 [amdgpu]]</span> *</span>ERROR</span>*</span> failed to halt cp gfx</span></span>
[45768.561065] amdgpu 0000:2f:00.0: amdgpu: MODE1 reset</span></span>
[45768.561070] amdgpu 0000:2f:00.0: amdgpu: GPU mode1 reset</span></span>
[45768.561151] amdgpu 0000:2f:00.0: amdgpu: GPU smu mode1 reset</span></span>
[45769.077273] amdgpu 0000:2f:00.0: amdgpu: GPU reset succeeded, trying to resume</span></span>
[45769.289571] amdgpu 0000:2f:00.0: amdgpu: RAP: optional rap ta ucode is not available</span></span>
[45769.289576] amdgpu 0000:2f:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available</span></span>
[45769.289581] amdgpu 0000:2f:00.0: amdgpu: SMU is resuming...</span></span>
[45769.289586] amdgpu 0000:2f:00.0: amdgpu: smu driver </span>if</span> version</span> = 0x0000003d, smu fw if version = 0x0000003f, smu fw program = 0, smu fw version =</span> 0x004e7300</span> (78.115.0)</span></span>
[45769.289590] amdgpu 0000:2f:00.0: amdgpu: SMU driver </span>if</span> version</span> not matched</span></span>
[45769.428583] amdgpu 0000:2f:00.0: amdgpu: SMU is resumed successfully</span>!</span></span>
[45769.513522]</span> amdgpu</span> 0000:2f:00.0:</span> [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG decode initialized successfully.</span></span>
[45769.513951] amdgpu 0000:2f:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0</span></span>
[45769.513953] amdgpu 0000:2f:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0</span></span>
[45769.513955] amdgpu 0000:2f:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0</span></span>
[45769.513957] amdgpu 0000:2f:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0</span></span>
[45769.513959] amdgpu 0000:2f:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0</span></span>
[45769.513961] amdgpu 0000:2f:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0</span></span>
[45769.513963] amdgpu 0000:2f:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0</span></span>
[45769.513964] amdgpu 0000:2f:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0</span></span>
[45769.513966] amdgpu 0000:2f:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0</span></span>
[45769.513968] amdgpu 0000:2f:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0</span></span>
[45769.513970] amdgpu 0000:2f:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0</span></span>
[45769.513972] amdgpu 0000:2f:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8</span></span>
[45769.513974] amdgpu 0000:2f:00.0: amdgpu: ring vcn_unified_1 uses VM inv eng 1 on hub 8</span></span>
[45769.513975] amdgpu 0000:2f:00.0: amdgpu: ring jpeg_dec uses VM inv eng 4 on hub 8</span></span>
[45769.513977] amdgpu 0000:2f:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 14 on hub 0</span></span>
[45769.516831] amdgpu 0000:2f:00.0: amdgpu: recover vram bo from shadow start</span></span>
[45769.533125] amdgpu 0000:2f:00.0: amdgpu: recover vram bo from shadow </span>done</span></span>
[45769.536136] amdgpu 0000:2f:00.0: amdgpu: GPU reset(</span>2</span>) succeeded</span>!</span></span>
[45769.572609] [drm:amdgpu_cs_ioctl [amdgpu]]</span> *ERROR*</span> Failed to initialize parser</span> -125!</span></span></code></pre></details>
When this happens, the GUI session becomes completely unresponsive and training processes die. The GPU resets and I can still SSH into the machine from my laptop, but I need to reboot every time since GNOME Mutter is bad at handling it.</p>
Crash Pattern (analyzed by Claude)</h3>

Page Fault</strong> → CPC (Command Processor Compute) fails at address 0x0, page table corruption</li>
MES Timeout</strong> → GPU's job scheduler stops responding (MES failed to response msg=3</code>)</li>
Soft Reset Fails</strong> → Can't unmap queues, recovery path broken</li>
MODE1 Reset</strong> → Full hardware reset succeeds, but desktop session already dead</li>
</ol>
Also seeing SMU driver if version not matched</code> (driver expects 0x3d, GPU reports 0x3f) — firmware/driver compatibility issue.</p>

Diagnosis by Claude</summary>
Diagnostic Analysis</h2>
Kernel Log Analysis (dmesg)</h3>
The crash follows a consistent pattern visible in kernel logs:</p>
Stage 1: Page Fault</h4>
amdgpu 0000:2f:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:xxx vmid:x pasid:xxxxx)</span></span>
amdgpu 0000:2f:00.0: amdgpu: in page starting at address 0x0000000000000000 from client 10</span></span>
amdgpu 0000:2f:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B3A</span></span>
amdgpu 0000:2f:00.0: amdgpu: Faulty UTCL2 client ID: CPC (0x5)</span></span>
amdgpu 0000:2f:00.0: amdgpu: MORE_FAULTS: 0x0</span></span>
amdgpu 0000:2f:00.0: amdgpu: WALKER_ERROR: 0x5</span></span>
amdgpu 0000:2f:00.0: amdgpu: PERMISSION_FAULTS: 0x3</span></span>
amdgpu 0000:2f:00.0: amdgpu: MAPPING_ERROR: 0x1</span></span></code></pre>
Interpretation:</strong></p>

CPC (Command Processor Compute)</strong> is the faulty client - indicates compute workload trigger</li>
Address 0x0000000000000000</strong> suggests null pointer dereference or page table corruption</li>
WALKER_ERROR + MAPPING_ERROR</strong> = Page table walk failure during address translation</li>
</ul>
Stage 2: MES Timeout</h4>
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3</span></span></code></pre>
Interpretation:</strong></p>

MES (Micro Engine Scheduler)</strong> is the GPU's internal job scheduler</li>
MES fails to respond to driver commands within timeout period</li>
This is the core bug - MES firmware cannot handle the error condition</li>
</ul>
Stage 3: Soft Reset Fails</h4>
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue</span></span>
amdgpu 0000:2f:00.0: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout</span></span></code></pre>
Interpretation:</strong></p>

GPU scheduler tries to recover by unmapping queues</li>
Timeout occurs waiting for GPU to respond</li>
Soft recovery path fails</li>
</ul>
Stage 4: MODE1 Reset</h4>
amdgpu 0000:2f:00.0: amdgpu: GPU reset begin!</span></span>
amdgpu 0000:2f:00.0: amdgpu: GPU reset succeeded</span></span></code></pre>
Interpretation:</strong></p>

Driver falls back to full hardware reset</li>
GPU recovers at hardware level</li>
BUT</strong> - Desktop session and applications are already dead</li>
</ul>
SMU Firmware Mismatch</h3>
Additional warning observed:</p>
amdgpu: SMU driver if version not matched</span></span></code></pre>
The driver expects SMU firmware version 0x3d but GPU reports 0x3f - indicates potential driver/firmware compatibility issue.</p>
Crash Triggers Observed</h3>
Different processes triggered crashes in different sessions:</p>

Xorg (display server)</li>
OBS (video encoding)</li>
Brave browser (hardware-accelerated compositing)</li>
Python/PyTorch processes</li>
</ul>
All crashes followed the identical MES failure pattern, suggesting the trigger is multi-context GPU scheduling, not any specific application.</p>
</details>
Fix attempts</h3>
To alleviate this, I added two options iommu=pt</code> and amdgpu.gfxoff=0</code> to GRUB_CMDLINE_LINUX_DEFAULT</code>:</p>
GRUB_DEFAULT=0</span></span>
GRUB_TIMEOUT_STYLE=menu</span></span>
GRUB_TIMEOUT=10</span></span>
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`</span></span>
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_enforce_resources=lax iommu=pt amdgpu.gfxoff=0"</span></span>
GRUB_CMDLINE_LINUX=""</span></span></code></pre>

iommu=pt</code>: IOMMU (a translation layer between devices and RAM) passthrough mode</li>
amdgpu.gfxoff=0</code>: Disable GFXOFF (aggressive power saving that's buggy on RDNA3)</li>
</ul>
I set the passthrough mode because I was getting IOMMU translation failures. After editing, run update-grub</code>:</p>
sudo</span> vim /etc/default/grub</span></span>
sudo</span> update-grub</span></span>
sudo</span> reboot</span></span></code></pre>
I also upgraded the kernel to a newer, possibly more stable version.</p>
Original:</p>
$</span> uname</span> -r</span></span>
6.2.0-39-generic</span></span></code></pre>
Update</p>
# Install the HWE kernel (should give you 6.8.x)</span></span>
sudo</span> apt update</span></span>
sudo</span> apt install linux-generic-hwe-22.04</span></span>
</span>
# Then reboot</span></span>
sudo</span> reboot</span></span></code></pre>
Post-update</p>
$</span> uname</span> -r</span></span>
6.8.0-90-generic</span></span></code></pre>
After enabling amdgpu.gfxoff=0</code>, I'm not getting freezes when I'm afk during training, but I still sometimes get random crashes when I actively use the desktop GUI. It seems that the multi-context contention between processes trying to access GPU like the browser doing hardware acceleration for video decoding is the source of issues.</p>
I'll dig deeper when I have more time, but this is the reality of using AMD GPUs at the moment.</p>
UPDATE</h3>
I disabled the hardware acceleration of browsers (Brave and Chrome) and disabled more power features by adding the amdgpu.ppfeaturemask=0xfffd7fff</code> flag, it survived for about 9 days before it crashes caused by AnyType (note taking app that presumably used GPU). My apps that use GPUs like the bevy game or image viewer sometimes experience lag spikes though. But this is good enough for now. I plan to upgrade to Ubuntu 24.04 and see if it improves the situation.</p>

For the record, here's my system info and some resources I found:</p>
System Configuration</h3>
Component</th> Details</th></tr></thead>

GPU</strong></td> AMD Radeon RX 7900 XTX (24GB VRAM) - Navi 31, gfx1100</td></tr>
OS</strong></td> Ubuntu 22.04 LTS</td></tr>
ROCm Version</strong></td> 6.4.3</td></tr>
Original Kernel</strong></td> 6.2.0-39-generic</td></tr>
DKMS Driver</strong></td> amdgpu/6.3.6-1697589.22.04</td></tr>
CPU</strong></td> AMD Ryzen (with Raphael integrated graphics)</td></tr>
</tbody></table>
Resources</h3>
This is a widely reported, ongoing issue</strong> with extensive documentation:</p>
Source</th> Issue Numbers</th></tr></thead>

ROCm GitHub</td> #3265, #3166, #3452, #2689, #1977</td></tr>
freedesktop.org GitLab</td> #2378, multiple others</td></tr>
</tbody></table>

A Dummy's Guide to AMD GPU Issues on Linux</a> - Comprehensive kernel parameter guide</li>
</ul>



Decouple layout calculations from rendering
2025-03-08T00:00:00+00:00
So, in the new version of my app, I use iced's 
     </span>          ];</span></ </span>         });</span></ }</span></span> </span> pub      ) {</span></spa        </span>   </span>        }</span>      };</span></ </span>       </span></sp       </span></sp      </span></sp   </span>          ];</span></         );</span></ }</span></span> However, I noticed that the rendered image 
Calculating the screen rect buffer at the 
let (_left, bottom, ...</span></spa let offset_y_ndc I did need this to make the screen uniforms 
<&# Therefore, I decided to decouple layout calculations 
<&# 
  iced's event loop is faster
 2025-03-01T00:00:00+00:00

custom shader widget to render images. I've been using a rendering pipeline and shader that directly calculate vertices of images since I'd like to keep the aspect ratio of images when user resizes them. I had a function updating vertices and screen rect buffer like this:</p> class="giallo-l">pub fn</span> update_vertices</span>(</span>&mut</span> self</span>, device</span>: &</span>wgpu</span>::</span>Device</span>, bounds_relative</span>:</span> (</span>f32</span>,</span> f32</span>,</span> f32</span>,</span> f32</span>)) {</span></span> let</span> (x, y, width, height)</span> =</span> bounds_relative;</span></span> let</span> left</span> =</span> 2.0</span> *</span> x</span> -</span> 1.0</span>;</span></span> let</span> right</span> =</span> 2.0</span> *</span> (x</span> +</span> width)</span> -</span> 1.0</span>;</span></span> let</span> top</span> =</span> 1.0</span> -</span> 2.0</span> *</span> y;</span></span> let</span> bottom</span> =</span> 1.0</span> -</span> 2.0</span> *</span> (y</span> +</span> height);</span></span> let</span> vertices</span>:</span> [</span>f32</span>;</span> 16</span>]</span> =</span> [</span></span> left, bottom,</span> 0.0</span>,</span> 1.0</span>,</span> // Bottom-left</span></span> right, bottom,</span> 1.0</span>,</span> 1.0</span>,</span> // Bottom-right</span></span> right, top,</span> 1.0</span>,</span> 0.0</span>,</span> // Top-right</span></span> left, top,</span> 0.0</span>,</span> 0.0</span>,</span> // Top-left</span></span> span> self</span>.</span>vertex_buffer </span>=</span> device</span>.</span>create_buffer_init</span>(</span>&</span>wgpu</span>::</span>util</span>::</span>BufferInitDescriptor</span> {</span></span> label</span>:</span> Some</span>(</span>"Quad Vertex Buffer"</span>),</span></span> contents</span>:</span> bytemuck</span>::</span>cast_slice</span>(</span>&</span>vertices),</span></span> usage</span>:</span> wgpu</span>::</span>BufferUsages</span>::</span>VERTEX</span> |</span> wgpu</span>::</span>BufferUsages</span>::</span>COPY_DST</span>,</span></span> ;span> fn</span> update_screen_uniforms</span>(</span></span> &</span>self</span>,</span></span> queue</span>: &</span>wgpu</span>::</span>Queue</span>,</span></span> image_dimensions</span>:</span> (</span>u32</span>,</span> u32</span>),</span></span> shader_size</span>:</span> (</span>u32</span>,</span> u32</span>),</span></span> bounds_relative</span>:</span> (</span>f32</span>,</span> f32</span>,</span> f32</span>,</span> f32</span>),</span></span> n> let</span> debug</span> =</span> false</span>;</span></span> let</span> shader_width</span> =</span> shader_size</span>.</span>0</span> as</span> f32</span>;</span></span> let</span> shader_height</span> =</span> shader_size</span>.</span>1</span> as</span> f32</span>;</span></span> let</span> image_width</span> =</span> image_dimensions</span>.</span>0</span> as</span> f32</span>;</span></span> let</span> image_height</span> =</span> image_dimensions</span>.</span>1</span> as</span> f32</span>;</span></span> let</span> vertices</span> =</span> self</span>.</span>vertices;</span></span> let</span> (_left, bottom, _right, _top)</span> =</span> (vertices[</span>0</span>], vertices[</span>1</span>], vertices[</span>2</span>], vertices[</span>3</span>]);</span></span> z-definition z-comment z-comment">    // Compute aspect ratios</span></span> let</span> image_aspect</span> =</span> image_width</span> /</span> image_height;</span></span> let</span> shader_aspect</span> =</span> shader_width</span> /</span> shader_height;</span></span> z-definition z-comment z-comment">    // Calculate scale factors - the key is to use the SMALLER dimension to maintain aspect ratio</span></span> let</span> (scale_x, scale_y, fit_mode)</span> = if</span> image_aspect</span> ></span> shader_aspect {</span></span> z-definition z-comment z-comment">        // Image is wider than container - fit width</span></span> let</span> scale</span> =</span> shader_width</span> /</span> image_width;</span></span> (scale, scale,</span> "FIT_WIDTH"</span>)</span></span> class="z-keyword"> else</span> {</span></span> z-definition z-comment z-comment">        // Image is taller than container - fit height</span></span> let</span> scale</span> =</span> shader_height</span> /</span> image_height;</span></span> (scale, scale,</span> "FIT_HEIGHT"</span>)</span></span> span> z-definition z-comment z-comment">    // Apply scaling to get final dimensions</span></span> let</span> scaled_width</span> =</span> image_width</span> *</span> scale_x;</span></span> let</span> scaled_height</span> =</span> image_height</span> *</span> scale_y;</span></span> an> z-definition z-comment z-comment">    // Calculate the scale factors relative to the container size</span></span> let</span> final_scale_x</span> =</span> scaled_width</span> /</span> shader_width;</span></span> let</span> final_scale_y</span> =</span> scaled_height</span> /</span> shader_height;</span></span> an> z-definition z-comment z-comment">    // Calculate the vertical gap that needs to be distributed</span></span> let</span> gap_y</span> =</span> shader_height</span> -</span> scaled_height;</span></span> an> z-definition z-comment z-comment">    // Calculate offset to center the scaled image vertically</span></span> z-definition z-comment z-comment">    // Fine-tune the vertical offset with a correction factor to match Image widget</span></span> z-definition z-comment z-comment">    // The bottom + 1.0 term accounts for asymmetric NDC space</span></span> let</span> offset_correction</span> =</span> 0.001</span>;</span> // Fine-tuning parameter (may need adjustment)</span></span> let</span> offset_y_ndc</span> =</span> (bottom</span> +</span> 1.0</span>)</span> *</span> (</span>1.0</span> -</span> final_scale_y)</span> /</span> 2.0</span> +</span> offset_correction;</span></span> let</span> screen_rect_data</span> =</span> [</span></span> final_scale_x,</span>      // Scale X </span></span> final_scale_y,</span>      // Scale Y</span></span> 0.0</span>,</span>                // Offset X (centered horizontally)</span></span> offset_y_ndc,</span>       // Offset Y to center vertically</span></span> span> z-definition z-comment z-comment">    // Update screen rect buffer</span></span> queue</span>.</span>write_buffer</span>(</span></span> &</span>self</span>.</span>screen_rect_buffer,</span></span> 0</span>,</span></span> bytemuck</span>::</span>cast_slice</span>(</span>&</span>screen_rect_data),</span></span> span> </code></pre> would "jiggle" slightly when resizing the window. At first, I assumed the layout math was off. But it turned out to be a deeper issue with how the layout and rendering were coupled.</p> shader level can be fragile. For example, I was using NDC-space vertex coordinates to calculate uniforms like this:</p> class="giallo-l">let vertices = self.vertices;</span></span> _right, _top) = (vertices[0], vertices[1], vertices[2], vertices[3]);</span></span> n> = (bottom + 1.0) * (1.0 - final_scale_y) / 2.0 + offset_correction;</span></span></code></pre> work correctly, but notice that NDC coordinates are in the range [-1.0, 1.0]. This means that even a tiny floating-point error (like 0.001) can shift the image by several pixels, especially on high-resolution screens.</p> x2F;iframe></div> from rendering calculations like iced does in their widgets. I just pre-calculate the layout bounds in layout(), and then just render the shader full screen within the layout bounds. This way, the shader side doesn't have to worry about the layout calculations, and the layout calculations are only done once in layout(). It became much more smooth as you can see in the video below!</p> x2F;iframe></div>
I spent the last week debugging the performance bottlneck of the wgpu integration version of my app. At first, I thought it was rendfering or state updates, but those parts only took 20~30ms, which should have given me at least 30FPS, but when I measured FPS it was less than 15 and very slow.</p>
I burned through 500 API calls on Cursor debugging this (lol), but it turns out that the bottleneck was the event loop itself</strong>. I noticed weird gaps between the end of window_event()</code> and the start of next event. What had really been bothering me was that the previous version of my app ran way faster on macOS (MBP with M1 chip) using iced's event loop, but the wgpu-integrated version doesn't.</p>
So I ended up hypothesizing that iced's event loop (iced_winit::program</a>) must be faster than winit's default one. I tested this theory by generating a new event loop with Claude 3.7, that adapts iced's event loop. It can be roughly summarized like this:</p>
use</span> std</span>::</span>sync</span>::</span>mpsc</span>::</span>{</span>self</span>,</span> Receiver</span>,</span> Sender</span>};</span></span>
use</span> winit</span>::</span>{</span></span>
    event</span>::</span>{</span>Event</span>,</span> WindowEvent</span>},</span></span>
    event_loop</span>::</span>{</span>ControlFlow</span>,</span> EventLoop</span>,</span> EventLoopProxy</span>},</span></span>
    window</span>::</span>WindowBuilder</span>,</span></span>
};</span></span>
</span>
enum</span> Control</span> {</span></span>
    ChangeFlow</span>(</span>ControlFlow</span>),</span></span>
    Exit</span>,</span></span>
}</span></span>
</span>
fn</span> main</span>() {</span></span>
    let</span> event_loop</span> =</span> EventLoop</span>::</span>with_user_event</span>();</span></span>
    let</span> proxy</span>:</span> EventLoopProxy</span><()></span> =</span> event_loop</span>.</span>create_proxy</span>();</span></span>
    </span></span>
    // Create communication channels for event handling</span></span>
    let</span> (event_sender, event_receiver)</span>:</span> (</span>Sender</span><</span>Event</span><'</span>_</span>, ()>>,</span> Receiver</span><</span>Event</span><'</span>_</span>, ()>>)</span> =</span> mpsc</span>::</span>channel</span>();</span></span>
    let</span> (control_sender, control_receiver)</span>:</span> (</span>Sender</span><</span>Control</span>>,</span> Receiver</span><</span>Control</span>>)</span> =</span> mpsc</span>::</span>channel</span>();</span></span>
</span>
    let</span> window</span> =</span> WindowBuilder</span>::</span>new</span>()</span></span>
        .</span>build</span>(</span>&</span>event_loop)</span></span>
        .</span>expect</span>(</span>"Failed to create window"</span>);</span></span>
</span>
    event_loop</span>.</span>run</span>(</span>move |</span>event, _, control_flow</span>|</span> {</span></span>
        *</span>control_flow</span> =</span> ControlFlow</span>::</span>Poll</span>;</span></span>
</span>
        // Send events to the queue instead of handling them immediately</span></span>
        if let</span> Err</span>(_)</span> =</span> event_sender</span>.</span>send</span>(event</span>.</span>to_static</span>()</span>.</span>unwrap</span>()) {</span></span>
            return</span>;</span> // Exit if sender is dropped</span></span>
        }</span></span>
</span>
        // Process control messages asynchronously</span></span>
        while let</span> Ok</span>(control)</span> =</span> control_receiver</span>.</span>try_recv</span>() {</span></span>
            match</span> control {</span></span>
                Control</span>::</span>ChangeFlow</span>(flow)</span> => *</span>control_flow</span> =</span> flow,</span></span>
                Control</span>::</span>Exit</span> => *</span>control_flow</span> =</span> ControlFlow</span>::</span>Exit</span>,</span></span>
            }</span></span>
        }</span></span>
</span>
        // Handle events from queue (non-blocking)</span></span>
        while let</span> Ok</span>(event)</span> =</span> event_receiver</span>.</span>try_recv</span>() {</span></span>
            match</span> event {</span></span>
                Event</span>::</span>WindowEvent</span> { event,</span> ..</span> }</span> => match</span> event {</span></span>
                    WindowEvent</span>::</span>CloseRequested</span> =></span> {</span></span>
                        control_sender</span>.</span>send</span>(</span>Control</span>::</span>Exit</span>)</span>.</span>ok</span>();</span></span>
                    }</span></span>
                    WindowEvent</span>::</span>Resized</span>(size)</span> =></span> {</span></span>
                        println!</span>(</span>"Window resized to: {:?}"</span>, size);</span></span>
                    }</span></span>
                    _</span> =></span> {}</span></span>
                },</span></span>
                Event</span>::</span>RedrawRequested</span>(_)</span> =></span> {</span></span>
                    println!</span>(</span>"Redraw triggered"</span>);</span></span>
                }</span></span>
                _</span> =></span> {}</span></span>
            }</span></span>
        }</span></span>
</span>
        // Request a redraw when needed (avoids redundant frames)</span></span>
        window</span>.</span>request_redraw</span>();</span></span>
    });</span></span>
}</span></span>
</span></code></pre>
I was able to roughly reproduce the performance of the previous version on my MBP, which is 40~50 FPS</strong> when rendering relevatively smaller images (~1080p). I uploaded a short comparison video on X</a>.</p>
I haven't fully understood how this works yet, but the key difference seems to be how this loop handles events asynchronously, while the winit's loop handles them synchronously. You can observe this in this part:</p>
let</span> (event_sender, event_receiver)</span>:</span> (</span>Sender</span><</span>Event</span><'</span>_</span>, ()>>,</span> Receiver</span><</span>Event</span><'</span>_</span>, ()>>)</span> =</span> mpsc</span>::</span>channel</span>();</span></span>
let</span> (control_sender, control_receiver)</span>:</span> (</span>Sender</span><</span>Control</span>>,</span> Receiver</span><</span>Control</span>>)</span> =</span> mpsc</span>::</span>channel</span>();</span></span></code></pre>
This setup queues events in a channel (mpsc::channel()</code>), allowing them to be handled separately from the main event loop. The event_sender</code> pushes incoming events into a queue, while the event_receiver</code> pulls them for processing without blocking the loop.</p>
While debugging this, I also noticed that sometimes winit produces a flood of CursorMoved</code> events, and every time this happens, the app processes them one by one, triggering a re-render for each event. I think this setup keeps the app responsive by throwing those spammy events into an async channel instead of blocking the loop. If you're building a wgpu + winit app, this might help you speed things up too. Here's the link to the full event loop</a> I used in my main.rs.</p>
Links</h2>

iced/winit/src
/program.rs</a></li>
my main.rs</a></li>
</ul>


How to load fonts in wgpu integration with iced
2025-02-21T00:00:00+00:00
I currently use the wgpu integration setup for my image viewer app and needed to load custom fonts (including an icon font) without using a Compositor. In iced 0.13.1, you usually set your fonts via Settings</code> and pass it like application(...).settings(your_settings)</code>. I found this part in iced_winit::program:run_action()</code>, and it seems like it is the Compositor</code> that loads fonts in the regular iced setup:</p>
Action</span>::</span>LoadFont</span> { bytes, channel }</span> =></span> {</span></span>
    if let</span> Some</span>(compositor)</span> =</span> compositor {</span></span>
        // TODO: Error handling (?)</span></span>
        compositor</span>.</span>load_font</span>(bytes</span>.</span>clone</span>());</span></span>
</span>
        let</span> _</span> =</span> channel</span>.</span>send</span>(</span>Ok</span>(()));</span></span>
    }</span></span>
}</span></span></code></pre>
iced/graphics/src/compositor.rs</code>:</p>
/// Loads a font from its bytes.</span></span>
fn</span> load_font</span>(</span>&mut</span> self</span>, font</span>:</span> Cow</span><'</span>static</span>, [</span>u8</span>]>) {</span></span>
    crate::</span>text</span>::</span>font_system</span>()</span></span>
        .</span>write</span>()</span></span>
        .</span>expect</span>(</span>"Write to font system"</span>)</span></span>
        .</span>load_font</span>(font);</span></span>
}</span></span></code></pre>
Compositor is not accessible in the wgpu integration example because we directly use Engine</code> to render things, but it turns out you can directly access the FontSystem like this:</p>
use</span> std</span>::</span>borrow</span>::</span>Cow</span>;</span></span>
use</span> iced_wgpu</span>::</span>graphics</span>::</span>text</span>::</span>font_system;</span></span>
</span>
fn</span> register_font_manually</span>(font_data</span>: &</span>'</span>static</span> [</span>u8</span>]) {</span></span>
    use</span> std</span>::</span>sync</span>::</span>RwLockWriteGuard</span>;</span></span>
</span>
    // Get a mutable reference to the font system</span></span>
    let</span> font_system</span> =</span> font_system</span>();</span></span>
    let mut</span> font_system_guard</span>:</span> RwLockWriteGuard</span><_></span> =</span> font_system</span></span>
        .</span>write</span>()</span></span>
        .</span>expect</span>(</span>"Failed to acquire font system lock"</span>);</span></span>
</span>
    // Load the font into the global font system</span></span>
    font_system_guard</span>.</span>load_font</span>(</span>Cow</span>::</span>Borrowed</span>(font_data));</span></span>
}</span></span></code></pre>
and call it after the Engine creation in Self::Loading() block:</p>
let</span> engine</span> =</span> Engine</span>::</span>new</span>(</span></span>
    &</span>adapter,</span> &</span>device,</span> &</span>queue, format,</span> None</span>);</span></span>
engine</span>.</span>create_image_cache</span>(</span>&</span>device);</span> // Manually create image cache</span></span>
</span>
// Manually register fonts</span></span>
register_font_manually</span>(</span>include_bytes!</span>(</span>"../assets/fonts/viewskater-fonts.ttf"</span>));</span></span>
register_font_manually</span>(</span>include_bytes!</span>(</span>"../assets/fonts/Iosevka-Regular-ascii.ttf"</span>));</span></span>
register_font_manually</span>(</span>include_bytes!</span>(</span>"../assets/fonts/Roboto-Regular.ttf"</span>));</span></span></code></pre>
Now you can use icon fonts like before!</p>
Links</h2>

iced/winit/src
/program.rs</a></li>
runtime/src/font.rs</a></li>
graphics/src/compositor.rs</a></li>
</ul>


Second TIL
2025-02-20T00:00:00+00:00
Placeholdder second note to debug html.</p>
// some code here...</span></span>
println!</span>(</span>"Hello World"</span>);</span></span></code></pre>


Trying the TIL section
2025-02-19T00:00:00+00:00
I usually do tech journaling on my local note taking app, but I realized that sometimes those notes are worth sharing. It feels too technical to publish on platforms like X and the volume tends to be too small for blog posts, so I made a designated section just to dump them. If this doesn't work I'll go back to just making blogs, but we'll see.</p>

`Links</h2> iced/winit/src /program.rs</a></li> my main.rs</a></li> </ul>`

Links</h2>

iced/winit/src /program.rs</a></li>
runtime/src/font.rs</a></li>
graphics/src/compositor.rs</a></li> </ul>

Today I Learned

Ubuntu 24.04 upgrade broke my GNOME desktop (ROCm leftovers)

The symptoms</h2>
After rebooting, I couldn't even get to a TTY login prompt initially. The system would boot, show the crash screen, and that was it. Recovery mode was the only way in.</p>

Issues I encountered</h2>

CPU to GPU Particle Migration in Bevy: The Billboard Illusion

The Actual Fixes</h2>
Once I understood what was really happening, the fixes were straightforward:</p>

Fix 2: UV Pivot</h3>
CPU main emitters use bottom-pivot - the UV zoom expands upward along velocity. My GPU zoom expanded from center, fighting the particle motion. Added configurable pivot to the modifier.</p>

Fix 3: SimulationSpace::Local</h3>
bevy_hanabi defaults to `SimulationSpace::Global</code>, which ignores Transform.scale</code>. CPU velocity was scaled, GPU was fixed. Switched to SimulationSpace::Local</code>.</p>`

AMD GPU Stability

Diagnostic Analysis</h2>

Kernel Log Analysis (dmesg)</h3>
The crash follows a consistent pattern visible in kernel logs:</p>

Decouple layout calculations from rendering

iced's event loop is faster

How to load fonts in wgpu integration with iced

Second TIL

Trying the TIL section

Today I Learned

Ubuntu 24.04 upgrade broke my GNOME desktop (ROCm leftovers)

The symptoms</h2> After rebooting, I couldn't even get to a TTY login prompt initially. The system would boot, show the crash screen, and that was it. Recovery mode was the only way in.</p>

Issues I encountered</h2>

CPU to GPU Particle Migration in Bevy: The Billboard Illusion

The Actual Fixes</h2> Once I understood what was really happening, the fixes were straightforward:</p>

Fix 2: UV Pivot</h3> CPU main emitters use bottom-pivot - the UV zoom expands upward along velocity. My GPU zoom expanded from center, fighting the particle motion. Added configurable pivot to the modifier.</p>

Fix 3: SimulationSpace::Local</h3> bevy_hanabi defaults to SimulationSpace::Global</code>, which ignores Transform.scale</code>. CPU velocity was scaled, GPU was fixed. Switched to SimulationSpace::Local</code>.</p>

AMD GPU Stability

Diagnostic Analysis</h2>

Kernel Log Analysis (dmesg)</h3> The crash follows a consistent pattern visible in kernel logs:</p>

Decouple layout calculations from rendering

iced's event loop is faster

Links</h2> iced/winit/src /program.rs</a></li> my main.rs</a></li> </ul>

How to load fonts in wgpu integration with iced

Links</h2> iced/winit/src /program.rs</a></li> runtime/src/font.rs</a></li> graphics/src/compositor.rs</a></li> </ul>

Second TIL

Trying the TIL section

The symptoms</h2>
After rebooting, I couldn't even get to a TTY login prompt initially. The system would boot, show the crash screen, and that was it. Recovery mode was the only way in.</p>

The Actual Fixes</h2>
Once I understood what was really happening, the fixes were straightforward:</p>

Fix 2: UV Pivot</h3>
CPU main emitters use bottom-pivot - the UV zoom expands upward along velocity. My GPU zoom expanded from center, fighting the particle motion. Added configurable pivot to the modifier.</p>

Fix 3: SimulationSpace::Local</h3>
bevy_hanabi defaults to `SimulationSpace::Global</code>, which ignores Transform.scale</code>. CPU velocity was scaled, GPU was fixed. Switched to SimulationSpace::Local</code>.</p>`

Kernel Log Analysis (dmesg)</h3>
The crash follows a consistent pattern visible in kernel logs:</p>

`Links</h2> iced/winit/src /program.rs</a></li> my main.rs</a></li> </ul>`

Links</h2>

iced/winit/src /program.rs</a></li>
runtime/src/font.rs</a></li>
graphics/src/compositor.rs</a></li> </ul>