41 Commits
Author SHA1 Message Date
Niko1221 11e02ea876 ISTA-DAS Coder: measured numbers in the menu text and the docs (KL, perplexity, speed on R9700 and RTX PRO 6000) 2026-11-01 22:29:19 +01:00
Niko1221 687527d7a3 Int3 merge f-0291-ds-left final (ea2e791d8): screens say 5 experts on 3+ RDNA4 cards 2026-11-01 13:15:20 +01:00
Niko1221 ea2e791d8b Screens and app say 5 experts on several RDNA4 cards that hold half of the experts, as the engine does
The engine gives 5 experts per word on two or more RDNA4 cards that together hold at least half of the experts (4 x R9700), but strata launch --plan, the Speed screen and the app's Speed label called Full quality the default there.
dsv41_fit.rdna4_faster() applies the engine's rule with the plan's own numbers: one card the run uses (on Windows one AMD card): yes; several: yes when the plan puts at least half of the set's experts on them (3 or more R9700 for every official set; two hold 37-47%, so they keep 6). strata launch uses it with the chosen model; the model catalog carries rdna4_faster per DeepSeek size for the app (NativeSize, Speed label); --speed help and docs/MODELS.md say it. Other makes and older Radeons are unchanged.
2026-11-01 13:14:36 +01:00
Niko1221 0f7159ca35 Int3 merge f-0291-ds-left (386d2e441): #4677 stop bound, 5 experts by default on one RDNA4 card 2026-11-01 13:07:20 +01:00
Niko1221 386d2e4416 DeepSeek: 5 experts per word by default on a single RDNA4 card (R9700, RX 9000); --experts N still wins
One R9700 holds under a fifth of a 2.25 bpw set, so the CPU lane and the SSD set the speed, as on the 16 GiB cards and the multi-card RDNA4 rule that already take 5.
1 x R9700 on p620 (125 GB RAM), 2.25 bpw, frozen expert profile, 5 interleaved pairs, 5 against 6 experts: decode 15.24 against 13.08 tok/s (+16%, 5 of 5 pairs), a scripted agent loop -24% wall time (5 of 5), the long-read loop -12% (5 of 5). KL against the 6-expert run 0.030 (6 against 6: 0.008); against the original model 0.1106 against 0.1067-0.1071. quality027 quick: 18 of 19 with 5 experts and with 6, the same task flagged in both.
ds4_experts_rule.hpp: experts_per_word() takes single_rdna4 (the engine passes rdna4() with one device); DS4_DEFAULTS=026 gives the model's 6 back. The Terminal's Speed words (strata launch --plan and screens), the app's Speed label (arch added to RunCard) and docs/MODELS.md say the same. Several RDNA4 cards keep the existing rule (they must hold half of the experts); the screens still do not mirror that one.
2026-11-01 13:04:39 +01:00
Niko1221 86c94204a1 Naming: the DeepSeek sets are ISTA-DAS on screen and in the docs; the ids (--model IST-DAS-2.25bpw) are unchanged and the new spelling is accepted too 2026-10-31 09:51:11 +01:00
Niko1221 5cfe96ee6a docs: DeepSeek on the Mac in MAC.md, MODELS.md and README 2026-10-27 21:23:06 +01:00
Niko1221 4a759f82d4 DeepSeek engine packages: add sm_89 (RTX 40) to the CUDA builds (#3935)
Problem: the strata-dsv41 packages were built for sm_86 and sm_120 (+ PTX 120). An RTX 4090 user was stopped at setup on 0.2.4.1; since
b750d757f an sm_86 package is accepted on an sm_89 card (cubin same-major rule), but the engine had no sm_89 image of its own, and the docs said
nothing about RTX 40 or about building the engine for a card the packages do not cover. The reporter built strata-dsv41 for 86-real;89-real
themselves and ran the 2.00 set at 40.2 tok/s on an RTX 4090 48 GB (theirs, --dspark on).

What changed:
- packaging/build_dsv41_cuda.sh and build_dsv41_windows.bat: the default architectures are now 86-real;89-real;120, so the DeepSeek CUDA 13
  packages list sm_86, sm_89, sm_120, compute_120 (Windows and Linux alike). The CUDA 12.9 line in the script header says ARCH="86-real;89".
- CMakeLists.txt: a build of strata-dsv41 with no -DCMAKE_CUDA_ARCHITECTURES defaults to 86-real;89-real;120 (the Qwen engine's default
  stays 120, and the warning now names the architectures it picked).
- strata_control/engine_component.py arch_native(): true when a package holds machine code for the card itself. resolve() and
  feed.select_engine() use it as the last tie-breaker, so with otherwise equal packages the one with the sm_89 image is taken on an RTX 40;
  an sm_86-only package still fits (no refusal).
- setup.py: the "engine not available" stop now points at the build recipe (docs/DEEPSEEK41.md); the developer line names the
  architecture to pass. The card list already said RTX 30, 40 and 50.
- docs/DEEPSEEK41.md, docs/MODELS.md: RTX 40 coverage, the reporter's measurement quoted as theirs, no claim of our own (we have no Ada card),
  and a section "Building the engine for your card".

Tests: tests/terminal/test_engine_manifest.py (arch_native; the build scripts and the CMake default name sm_89 and both OSes agree; the
package list they give is sm_86 sm_89 sm_120 compute_120; an sm_89 card is accepted and prefers the package with sm_89). tools/test_setup_dsv41.py
unchanged and passing.

Not covered: no run on an Ada card (gate script in phaseA-tests/gh027/gates/3935-ada-dsv41.sh).
2026-10-26 19:42:11 +01:00
Niko1221 e7e48be2c9 Strix Halo (gfx1151): an 8,192-token prompt chunk on the unified-memory APU (11-15% faster prompts)
The engine's prompt-chunk rule returns 1,024 when a single card holds half or more of the experts; it was calibrated on
cards that hold most of them (4 x R9700).  On the 128 GB Strix Halo (share 0.62, one shared pool) the bigger chunk wins:
measured with the 2.00 bpw set, engine 0.1.51, 2026-10-25: 4K prompt 78.7 -> 87.2 tok/s, 8K 108.9 -> 125.1, 32K 155.2 ->
176.9.  Decode is unchanged (16.53 -> 16.59): the chunk buffers take ~5 GB from the GPU expert tier (81.9 -> 76.6 GB) and the
RAM store's hit rate rises (68.6% -> 76.8%) to compensate.

dsv41_prefill_chunk_args(cards, ram) writes --prefill-chunk 8192 for an integrated Radeon only, and only when the whole pool
(the RAM Windows sees plus the BIOS carve-out) is at least 64 GB; a discrete card or a smaller unified PC keeps the engine's
choice, and STRATA_DSV41_NO_BIG_CHUNK=1 turns it off.  The chunk changes the prompt GEMMs' summation order, not the model: the
repo's chunk-size KL check reads 1024 0.1705 / 2048 0.1692 / 4096 0.1688 / 8192 0.1695.  Test:
tests/terminal/test_dsv41_prefill_chunk.py (5 cases).

Also repairs UTF-8 damage in README.md, docs/STRIX_HALO.md and docs/MODELS.md from an earlier PowerShell edit (the middots,
em dashes and arrows had been double-encoded; no text changed).  No engine rebuild is needed: the existing signed dsv41 package
accepts the flag.
2026-10-25 18:54:22 +01:00
Niko1221 932bda54bd Strix Halo: the DeepSeek engine follows --feed, and the unified plan counts the BIOS carve-out
Found by the clean-user test on strix: 'strata launch --feed DIR' read the local feed for its own engine
check and then setup went to GitHub for the DeepSeek package, so a local (or any non-default) feed never
served the DeepSeek engine.  setup's get_dsv41_engine/upgrade_dsv41_engine take the feed, install_dsv41
passes --feed, and runner.setup_args hands --feed to setup (a test in test_launch_dsv41).

The unified-memory plan counted only the RAM Windows sees (64 GB on the owner's box) and ignored the 64 GB
BIOS carve-out the GPU owns: 128 GB in one pool.  uma_total_gb() adds the carve-out (or the GPU figure less
its shared part), so the plan now says about 109 GB of the 2.00 set's 132 GB stay in memory and 23 GB are read
from the SSD; the docs and the test fixtures use the 128 GB box.  The 'measured' text says 128 GB unified too.
2026-10-25 17:00:58 +01:00
Niko1221 6c70d4bc5d Strix Halo (gfx1151) on Windows: DeepSeek V4.1-Flash support and the 0.2.6 shared-memory fix
The Windows AMD DeepSeek engine package (feed member dsv41, windows-x86_64-hip-rdna3, arch gfx1151) is built from this
branch and installed as its own package; these are the code changes it needs.

- ds4_model.cu: on an integrated GPU the CPU lane's experts are no longer copied into RAM by the auto rule.  The GPU's
  expert tier and that copy are the same shared memory: on the 64 GB Strix Halo the GPU held 82 GB of experts, the rule
  saw 62 GB 'free' and copied 53 GB, and an 8K prompt did not finish in 11 minutes.  Found 2026-10-25 on strix; the
  corrected build does the same prompt at 108.9 tok/s (4K 78.7), code answers 17.6 tok/s, chat 11.0.  DS4_COPY_ALL=1
  still forces the copy for a test.
- dsv41_engine.py: lib_dirs()/start_env() put the package's BUILD.json lib_dirs on PATH/LD_LIBRARY_PATH (a Windows HIP
  package keeps hipBLAS/rocBLAS in rocm/bin, or a clean PC fails with 0xC0000135); the upgrade test-start uses it.
- setup.py: the dsv41 engine's library dirs come from the package (so the run config carries rocm/bin), the unsupported-card
  text names Ryzen AI Max on Windows, and the manual package hint names the .tar.gz the release page actually has.
- runner.py: the same library dirs for the app/Terminal path.
- dsv41_fit.py: a unified-memory plan for the official IST-DAS sets (one pool, what stays in RAM, what is read from the SSD,
  measured 14-16 tok/s on code, 10-11 on chat, 4K 78 / 8K 109), never a refusal; tools/strata_mcp.py uses it for the app
  catalog's on-this-PC line.
- Docs: STRIX_HALO.md (DeepSeek section with speeds, driver 26.10.1, memory behaviour, limits), DEEPSEEK41.md, MODELS.md,
  AI_REFERENCE.md, README.md, packaging/README.md (the Windows AMD package recipe).
- Tests: tests/terminal/test_dsv41_fit.py (7) and 4 new tests in test_dsv41_engine.py (lib dirs, feed selection for gfx1151).
2026-10-25 16:41:49 +01:00
Niko1221 ed4b4db405 docs and packaging: the owner's 2026-10-23 guide set brought in for 0.2.5 (one installer per system, engine downloaded on first start, DeepSeek in the app and the Terminal with three sets and the Speed choice, install.sh form kept, versions 0.2.5 and 0.1.50, source setup labelled as the developer path) 2026-10-25 11:28:02 +01:00
Niko1221 76f90e5843 Fix #3425: the memory tiers count RAM + VRAM less 5 GB that Windows and the system keep (setup.py and tools/strata_mcp.py, one constant each; the app and strata launch read the engine's pick; the Mac keeps its own macOS share) 2026-10-21 07:03:33 +02:00
Niko1221 aae92ceb26 Gyro: decode speed on NVIDIA (docs, 0.2.2 notes), Gyro-M's slowdown against Q2_0 16-21%
GYRO.md gets the measured RTX 3060 numbers of the shared-memory codebook / 8-lane row kernels (Gyro-S 53.6 -> 62.8 tok/s, Gyro-M 50.6 -> 56.1, 5 interleaved pairs, identity gate identical), the release notes one line, and the places that said Gyro-M decodes about 20% slower than Q2_0 now say 16-21% (RTX 3060 12 GB after the kernels: 16%, R9700: 17-21%). The translated READMEs keep the old figure.
2026-10-21 00:14:08 +02:00
Niko1221 21b0fdb0d4 Merge f-022-int into f-022-macgyro: Gyro is listed as supported on Intel Arc and on the Mac (docs, seven READMEs, release notes keep both bullets) 2026-10-20 20:55:53 +02:00
Niko1221 79946b9c4f Gyro on Intel Arc: README and MODELS say so, ctest cases for the trellis kernels, setup's Gyro memory warning reads the real RAM on the Intel path 2026-10-20 20:13:49 +02:00
Niko1221 ca40c88ef4 Docs: Gyro on the Mac (MAC.md, GYRO.md, MODELS.md, README, 0.2.2 release notes) 2026-10-20 19:51:16 +02:00
Niko1221 9f5488e3b2 Merge branch 'f-021-arcvis' into f-021-int
# Conflicts:
#	docs/MODELS.md
#	strata_control/vision_reader.py
#	tools/vision/CMakeLists.txt
#	tools/vision/strata_vision.cpp
2026-10-19 21:42:12 +02:00
Niko1221 cac4816afd Intel Arc pictures: on by default for the Alchemist cards (CPU reader), Battlemage stays opt-in; SYCL GPU picture reader (strata-vision-sycl) for --vision gpu; reader rule in vision_reader.py; tests and docs 2026-10-19 21:40:50 +02:00
Niko1221 509466a668 Mac pictures: signing smoke checks strata-vision, docs and the 7 READMEs say the Mac reads pictures
sign-and-notarize.sh starts strata-vision --version in the signed engine folders (it already signs every Mach-O).
MAC.md carries the M4 numbers (0.45 s on the GPU, 50.7 s on the CPU for a 260-token picture) and the rule.
2026-10-19 21:26:49 +02:00
Niko1221 aa82a88639 Recommend by the owner's memory tiers (RAM + VRAM): 40 GB Swift 1.5 IQ2_XS with Gyro-M named, 48 GB IQ3_XXS, 64 GB IQ3_S; MODELS.md Pick by memory 2026-10-19 08:26:54 +02:00
Niko1221 5e7b9a8301 Docs: plain-wording pass on the 0.2.0 text (fewer mid-sentence bolds, direct phrasing) 2026-10-19 08:01:47 +02:00
Niko1221 2b209b406d Docs consistency pass: pictures on by default on NVIDIA and AMD (Intel Arc off for now), seven monitor views, area prefix for issue and PR titles in AGENTS.md 2026-10-19 08:00:26 +02:00
Niko1221 b27c46cbd6 docs: Mac, AMD, Intel, older GPUs and multi-GPU for 0.2.0
MAC: the .dmg and the Terminal bring the Metal engine; pictures only with the source build. AMD_HIP: the 24 GB
picture rule and the measured R9700 GPU reader. INTEL: the grouped XMX label is engine 0.1.45.3 (not 0.1.48), plus
the A750 prompt-hang fix (fca3c5958; STRATA_PF_DMA_PAGEABLE=1 restores the old copy). INTEL_ARC: maintainers now test
on a B70 and an A750; where the Intel engine comes from. OLDER_GPUS: the P100 sm_60 defaults (STRATA_SM60_PERF).
MULTI_GPU: two models on two cards, one make per engine. MODELS and TROUBLESHOOTING: the Mac and Intel Arc have no
picture reader yet.
2026-10-19 07:15:14 +02:00
Niko1221 afe92c1727 docs: models, NVFP4, Gyro, Qwen3.6 and troubleshooting for 0.2.0
Pictures are on by default (CPU reader under 24 GB, GPU reader from 24 GB, every make; no Mac reader yet).
Gyro and NVFP4-QAD read pictures; Gyro needs engine 0.1.45.1+ and is correct on RTX 50 since the SwiGLU guard.
The three NVFP4 versions get their app names. A Qwen3.6-35B-A3B section, the app and Terminal ways to add a model,
and engine versions on the older speed tables. Troubleshooting: no-engine warning, needs a newer engine / Update
engine, Mac xattr steps, strata doctor, Save logs. Private test-notes references removed.
2026-10-19 07:07:54 +02:00
Niko1221 c3e9480592 catalog: one plain line each for NVFP4 (best quality of the NVFP4 versions) and NVFP4-QAD (NVIDIA's FP4, trained for FP4, slightly faster on short prompts) 2026-10-16 22:44:58 +02:00
Niko1221 0da73d9159 FP4-Local prepare: separate step marks (the pack's own files were overwritten), scale tensors in the checkpoint-direct pack; docs section 2026-10-16 20:06:19 +02:00
Niko1221 02bbf51fb7 Gyro: the Hadamard row kernels go up in slices of 65535 rows (gridDim.y limit): the FP16 prompt path rotates T*K rows, which a 16K-token chunk takes past it (invalid configuration argument on a build without the fork's MMQ) 2026-10-15 23:46:50 +02:00
Niko1221 9269262f13 docs/QUANTS.md: UD-IQ4_XS and the Q6_K MMQ numbers, PROMPT_DIRECT and the budget-mode I/O A/Bs, several cards; MODELS.md UD-IQ4_XS quality 2026-10-13 05:26:35 +02:00
Niko1221 dd5f09a50e docs: QUANTS.md speed, bound, CPU pool, dense GEMV, HC and images; MODELS.md one table for Unsloth's five files (old anchors kept); UNSLOTH_Q4/Q6 status; README 2026-10-13 00:30:02 +02:00
SuperLee 52c743d550 mcp: let the swift family take IQ3_S too; docs
The MCP server's FALLBACK_MODELS carries its own copy of the model
table, so #1688's setup.py fix leaves the MCP install path rejecting
--family swift --model IQ3_S. Drop the families gate there as well,
flip the validation test, and update the three doc lines that say
IQ3_S is original-model-only.

Measured on an RTX 3090 pair (engine 0.1.40.3, Swift IQ3_S, 200K
context, MTP spec on): 91-137 tok/s decode, expert cache hit rate
96-99%, KV streaming 98.6-99.6% VRAM hits.
2026-10-09 15:15:53 +02:00
Niko1221 9b5e9ab13a 0.1.41 merge cleanups: bench key placeholder, B65 README author text, calibration time text, fixups.py regenerates the run-time spin bound 2026-10-08 09:58:59 +02:00
Thomas Weaver 9227973b36 PLE table as Q8_0 (Unsloth's UD-Q6_K_XL) + docs
PleTable accepts per_layer_token_embd.weight as Q8_0 (170-B rows): the
UD-Q6_K_XL file ships its PLE table in Q8_0, not IQ4_NL. The row reader
is already parameterized by bytes-per-row; only the type check, a
dequantize_q8_0 block loop (5 x 34 B) and the PLE_ROW_BYTES_MAX bump
(160 -> 170) were new. No GPU kernel changes: gather outputs floats.

- ple_reader_test --selftest also runs 170-B rows (90/110 were already run)
- ple_q8_parity: real-artifact Q8_0 PLE rows against ggml's reference
  dequantizer, through Mmap and Direct (bit-exact on the synthetic
  fixture from tools/ple_q8_fixture.py)
- docs/UNSLOTH_Q6.md: the manual workflow, verified shard inventory
  (169.2 GB, 6 shards, table alone in shard 3), pending real-run numbers
2026-10-05 19:57:36 +02:00
Niko1221 91b0f53659 setup: Unsloth's UD-IQ4_XS is a regular choice (no longer experimental); UD-Q4_K_XL stays experimental
- "experimental" is per model now: MODELS["UD-Q4_K_XL"] keeps it, the unsloth family and UD-IQ4_XS drop it. The
  first menu lists the family without [experimental], with a one-line about (UD-IQ4_XS: a 94 GB download; under
  ~80 GB of RAM part of its experts are read from the SSD). Its size menu lists UD-IQ4_XS first (the default) and
  UD-Q4_K_XL second; an experimental size always sorts last. --model names are unchanged.
- UD-IQ4_XS: no EXPERIMENTAL warning, --check verdict without it. Images are asked (off by default), per model: the
  engine's image path has no restriction for this pack, which uses the original model's image encoder; not yet run
  with images. UD-Q4_K_XL keeps images off.
- MCP: the fallback tables mirror setup's (per-model experimental/vision), sizes in setup's order, per-size
  "experimental" and "images", the vision check per model.
- Docs: README and its six translations, MODELS, UNSLOTH_Q4, AI_SETUP, MCP_SERVER.
- Tests: the menus, the default, --model by name, images, --check, the pack/tokenizer paths; the golden configs
  are unchanged.
2026-10-04 13:24:29 +02:00
Niko1221 5b735eccb2 setup: Unsloth's UD-IQ4_XS as an experimental choice (#621)
UD-IQ4_XS sits between IQ3_S and UD-Q4_K_XL: IQ3_S gate/up experts (IQ4_XS in one layer) with IQ4_NL downs (Q8_0 in
five layers), 59.5 GB of them, and UD-Q4_K_XL's dense side. The engine's kernels already take these formats; it was
packed (iq_pack.py --compat-bf16) and run on the Strix Halo, not yet on NVIDIA.

- MODELS["UD-IQ4_XS"] in the unsloth family: three shards pinned at the same revision 38bb39e with their sizes and
  SHA-256 (the Hub's LFS pointers), the RAM budget like UD-Q4_K_XL (budget, one GPU, no images, --compat-bf16 pack,
  no experts.bin), engine 0.1.38 or newer (the fused-layout fix for packs not every layer of which is covered).
- A model can have its own shard pattern and count (model_file / model_shards); budget_model() tells which Unsloth
  model a config runs, for the #498 multi-GPU messages and RAM need.
- The AMD question (#429) stays for UD-Q4_K_XL only (nvidia_only): UD-IQ4_XS's formats have AMD prompt kernels.
- --gguf-dir accepts UD-IQ4_XS files (#444's list says so).
- UNSLOTH_Q4.md: its files, what setup does, what is known (Strix Halo), and the BF16 rounding of the hyper-connection
  projections that every --compat-bf16 pack has (not changed here). MODELS.md: a paragraph.
- test_setup_unsloth: pins, budget, a mocked install, the engine check, no AMD question, the config read back.

UD-Q4_K_XL's install, its tests and every other model's config are unchanged.
2026-10-03 18:36:44 +02:00
Niko1221 0b1c763a75 Docs: the five reading errors #604 found (the sixth, the n-gram table's unbuffered reads, is in #605's commit)
- MODELS.md: the RAM rule is the experts + ~10 GB (setup's arena_gb), not shard 1 + 10 GB; the sizes per model.
- DETAILS.md: prompts are read in chunks of up to 8,192 tokens (32,768 opt-in), not 2,048; Q2_0's AVX-512 pack is
  ~40 GB on disk = 34 GB of experts plus the dense weights.
- README: the NVIDIA speed table says which engine measured which row (Q2_0 0.1.36, the others 0.1.26).
- expert_cache.hpp: the comment that the cache "does not yet compute anything" is gone.
2026-10-03 18:32:16 +02:00
Niko1221 f9e6576c5a docs: the Coder is a 32 GB fit, not the pick for general use
It keeps 256 of the 512 experts, chosen on code data, so it is weaker outside
code and in other languages; for general use, or when RAM allows, MODELS.md
now points to the full models.
2026-10-03 02:11:36 +02:00
Niko1221 2aa6ace036 docs: 0.1.36's speed (fused Q2_0 prompt experts, cluster decode kernels) and their switches 2026-10-02 18:24:15 +02:00
Niko1221 6f8536aed1 docs: the Coder is weaker outside code, Chinese/CJK text included; the unpruned sizes for that (#438)
README and docs/MODELS.md said only "Weaker outside coding". #438 measured Chinese answers wrong or looping on the
Coder where English was fine; both now say plainly that this includes Chinese and other CJK text and point to the
sizes that keep every expert (Q2_0, IQ2_XS, IQ3_S).
2026-10-02 09:39:14 +02:00
Niko1221 eb8bb8bcd9 README, MODELS: the AMD baseline - RX 9070 XT + Ryzen 9 3900X + 47 GB RAM (Q2_0, IQ2_XS, the Coder)
Measured with setup's own install and the README's speed method on the AMD box.
2026-10-02 03:08:05 +02:00
Niko1221 f938412499 docs: a short README for regular people; the details move to INSTALL, MODELS, TROUBLESHOOTING, HOW_IT_WORKS
README.md (279 -> ~180 lines): what it is, speed on an NVIDIA and an AMD baseline PC side by side (the AMD
numbers are TODO-AMD placeholders until the RX 9070 XT baseline is measured), what you need with NVIDIA and AMD
as equals, install by asking an AI assistant (docs/AI_SETUP.md, MCP server) or by hand, pick-by-RAM table,
using it, the four common problems, how it works with the two diagrams, Buy Me a Coffee button below the speed
table and at the end. Its anchors other pages use (#which-model-should-i-pick, #install, #using-it,
#something-went-wrong, #how-does-it-work) are kept.

Everything the README had moves, nothing dropped: docs/INSTALL.md (requirements, Windows, Linux, AMD cards,
several cards, Docker, updating, where things are stored, setup's questions incl. rope scaling / images /
speed projection, calibrate, all options), docs/MODELS.md (speed per size, sizes, will it fit, low-RAM, Coder,
Swift 1.5, Unsloth UD-Q4_K_XL, Orca), docs/TROUBLESHOOTING.md (the README's problems plus AMD ones),
docs/HOW_IT_WORKS.md (the longer explanation, credits, license). New docs/AI_SETUP.md (instructions for an AI
agent installing Strata for a user) and AGENTS.md. .github/FUNDING.yml (buy_me_a_coffee: strataengine).
AMD_HIP.md loses "Experimental" in its title and intro; DETAILS.md lists the AMD cards and points to the new pages.
2026-10-01 20:08:58 +02:00