docs: clarify GPU benchmark platform context

[Kewe63]

Overview

Fixes #106 (the documentation request).

The issue asks for an OS note so readers do not interpret published CUDA speedups as expected Windows performance or a cross-vendor hardware comparison. The existing benchmark records identify Linux binaries and Ubuntu-based images, but this context is not prominent in the GPU setup guidance.

What changed

• README: add benchmark platform context linking the existing Vast.ai and Clore.ai measurements; distinguish native CUDA from wgpu/Vulkan and caution against extrapolating Linux measurements to Windows.
• Benchmark documents: add prominent Linux/engine notes and link back to the README explanation.
• Attribute the reported Windows CUDA crash to the issue rather than presenting Windows incompatibility as an independently verified fact.
• Preserve all existing benchmark table rows and measured values. No runtime or kernel changes.

Validation

• git diff --check and staged diff check: passed.
• cargo +stable fmt --all -- --check: passed.
• taplo fmt --check: passed.
• Python documentation checks across all three changed files: local link targets and the new heading anchor resolve; all benchmark table rows are identical to the base revision.
• Reviewed the wording against the existing Linux binary/container records and issue thread.
• Build, Clippy, runtime tests, and new GPU measurements were not run: documentation-only change. The CI workflow excludes docs/** and root Markdown files.
• The pinned Rust toolchain setup hit a local existing cargo-clippy file conflict; formatting was successfully checked using the installed stable toolchain instead. No toolchain files were changed.

Risks and mitigations

Documentation-only; no runtime behavior changes. The notes describe the recorded measurement environment, not a universal claim that CUDA cannot work on Windows. No unsupported OS-specific hashrates are added.

Follow-ups

HIP optimization and diagnosis of the reported Windows CUDA crash are outside this documentation request. Published release text outside the repository is not modified by this PR.

[Tanukichiiiiii]

Why this matters beyond my own hardware

Some context on why I think this is worth the maintainers' time, rather than
just a curiosity about one card.

The network is shrinking. Over the last 48 hours network hashrate went
18.8 -> 9.37 -> 7.30 TH/s while the price moved $33.6 -> $12.95. In that
situation, opening the miner to a GPU vendor that currently cannot participate
is not a nicety — it is hashrate defence. Security scales with the number of
people who can mine.

The vendor split is not evidence of demand. quanpool currently reports
~99% of pool hashrate on the CUDA build. That is not because AMD owners are
uninterested; it is because at ~1/4 the throughput they cannot cover power
costs. The causality runs the other way round from how it looks: AMD owners
are absent because the path is slow, so measuring demand from current
participation will always say "no AMD users".

The work is not starting from zero. HIP is close enough to CUDA that
__device__, __global__, __constant__ and __umul64hi all carry over
unchanged. I have already done the mechanical port — only the seven inline-PTX
blocks needed rewriting — and it builds and runs correctly on gfx1200. The
remaining work is optimisation against RDNA's register file and dependency
latency, not a rewrite.

I am happy to hand over the ported kernel, the A/B harness, and to run any
experiment you want tested on real RDNA4 hardware. What I cannot do alone is
know which direction is worth pursuing — four of my own hypotheses were wrong.
If someone who knows the kernel's design says "try X", I will measure X and
report back.