Submit a row for your chip
Any chip measured with the suite can go on this site, with its own page and its result files next to it. This page says how to send one, what gets published and what does not, and the rules a submission has to meet.
- How to run the suite and send the files
- What is published, and what is not
- What makes a row, and what does not
Send a chip, get a row
Run the suite on your chip and the result goes on this site with its own page, under your chip's name, with every file you sent next to it.
# install once, in its own virtual environment (Python 3.10 or newer) python3 -m venv chip-env && source chip-env/bin/activate pip install ai-chip-integrity # the full run: every probe and its self-test, ten OCP result files chip-integrity run --name NAME
Then open the form and drag the files in. No account beyond GitHub, no pull request, nothing to install for the submission itself.
Submit a row ยท The longer instructions
A run on a rented GPU costs about a dollar and takes under an hour on most cards. On an Apple or AMD laptop GPU it runs on the machine you already have.
What gets published
- The chip name, as you write it. Make it the name you want in the table.
- The result files themselves, unchanged, in the repository, so anyone can check the row against them.
- Everything the files record: the probe versions, PyTorch, CUDA and driver versions, the shapes, the precisions, the error counters and the verdicts.
- A page for the chip, generated from those files, showing how close each precision came to its proven error limit.
What does not
- Your name or your company, unless you ask for it. The row is about the chip.
- Anything not in the files. The tables are regenerated from the result files, so a row cannot claim more than its evidence.
- Nothing is edited to look better. A result outside its bound is published as that, with the reason where the probe measured one.
If you would rather not post in public, run it, keep the files, and read your own verdicts. The tool is MIT licensed and needs nothing from this site.
What makes a row
- A full run, not
--quick. Quick mode uses tiny sizes to check the wiring, and never becomes a row. - The self-tests must be there too. Half the files plant faults on purpose, and a clean result only means something next to proof that the checks fire.
- Files as the tool wrote them. Nothing edited, nothing removed.
- One chip per row. If a host has several cards, run each one and send them separately.
- A fault is more useful than a pass. If a probe found something, send it with whatever you know about the card. That is the whole point of the project.
Submissions are measured work by whoever sent them, not re-measured here, and each row says which version of the suite wrote it.