Write a good bug report
Use the report template and thecollect-rocm-report.shscript. GPU, gfx ID, OS, kernel, ROCm prefix, backend, the exact command, and the first error line. Attach a saved rig when you post on theforum.
Upvote and add data — do not +1-spam
If the issue already exists, add your rocminfo excerpt, kernel, and whether the published workaround worked. A thumbs-up is fine. A comment that only says “+1” or “any update?” is noise. Link the tracker row so people can find the same thread later.
Test nightlies and RCs
When an AMD engineer asks for a nightly, try it on a spare disk or container — not as a silent overwrite of a working daily driver. Record the artifact date. We do not invent version pins here. TheRock and ROCm releases are the upstream homes:
Contribute benchmarks
tok/s without model, quant, context, backend, gfx, and whether KV is f16 is not a benchmark. Post in Benchmarks. This site’s house rules still apply: llama.cpp first for consumers, Q5 over Q4, never below Q4, no invented numbers. First-party figures stay labeled “Measured on our rig” or they stay TODO.
Docs and translations
Fix a sentence on this site: contributor guidelines. ROCm’s own docs take pull requests againstROCm/ROCm — read Contributing to ROCm docs.
Report what works
Negative space is useful too. TheWorks on my rig form attaches a saved rig and (when the forum is on) opens a Show Your Rigthread. Say the command that ran, not a vibe.