basalt

문제 · 지원 GPU · 작동 방식 · 빠른 시작 · 측정된 것, 가정된 것이 아닌 것 · 발견 사항 · API · 방법 · 로드맵 · 클린룸

문제

NVIDIA GPU 명령어는 128비트이며, 그중 21비트는 전혀 명령어가 아니다. 이들은 스케줄링 제어 워드, stall부터 reuse까지다: 다음 명령어를 발행하기 전에 몇 사이클을 기다릴지, 어떤 스코어보드에 신호를 보낼지, 어떤 것을 기다릴지, 그리고 어떤 피연산자가 재사용 캐시에서 제공될 수 있는지.

하드웨어는 그 어떤 것도 검사하지 않는다. sm_120에는 고정 레이턴시 명령어에 대한 인터록이 없다. 실리콘은 제어 워드를 만든 무엇이든 신뢰한다. 스톨 카운트가 다음 명령어가 소비하는 값의 레이턴시보다 짧으면, 아무런 폴트도 발생하지 않고, 스톨도 없으며, 경고도 출력되지 않는다. 명령어는 아직 기록되지 않은 레지스터를 읽고, 매번 전체 속도로 스테일 데이터에 대해 연산한다.

이상한 종류의 버그다. 크래시가 나지 않는다. 디버거에 나타나지 않는다. 단지 틀린 숫자를 만들어낼 뿐이며, 행렬 곱셈이나 어텐션 커널에서는 눈에 띄게 무너지는 모델이 아니라 약간 잘못 학습되는 모델을 의미한다.

가장 저렴한 세 인코딩이 고장난 것들이며, 어디에서도 그것을 보고하지 않는다. 또한 왼쪽 막대가 무엇을 하는지 주목하라: 0 스톨은 0 사이클이 아니라, 미해결 결과를 기다리는 별개의 안전한 인코딩이며 예약된 명령어보다 약 9배의 비용이 든다. 그것을 0으로 읽는 체커는 올바른 프로그램을 고장난 것으로 판정할 것이다.

이 아키텍처용 기계어를 생성하는 도구들은 레이턴시 모델에서 그 제어 비트를 할당한다. basalt는 그 답을 검사하는 도구다.

NVIDIA가 결코 출시하지 않은 검사

NVIDIA는 그 21비트를 작성하는 컴파일러를 제공한다. 그러나 그 비트를 다시 읽어 안전하다고 말해주는 것은 제공하지 않으며, 다른 누구도 제공하지 않는다.

NVIDIA GPU용 어셈블러는 10년 동안 존재해 왔고, Blackwell 인코딩은 이전에 리버스 엔지니어링된 적이 있으며, sm_120에 대한 사이클 수준 특성화가 공개되어 있고, 이 아키텍처용 공개 어셈블러 하나는 이미 스케줄링 제어 비트를 직접 할당하고 카드에서 자체 커널을 실행해 답이 올바르게 나오는지 확인한다. 모두 사실이지만, 그중 어느 것도 다음 주장은 아니다:

다른 어떤 도구도 자신이 생성하지 않은 cubin을 건네받아 그 스케줄링 제어 비트가 안전한지 말하라고 요구받을 수 없다.

당신의 컴파일러가 그 cubin을 생성했거나, 라이브러리가 그것을 배포했거나, 누군가 손으로 작성했을 것이다. 그리고 지금까지 물어볼 방법이 없었다. 하드웨어 인터록이 없는 아키텍처에서 그것이 "실행되었다"와 "정확하다"의 차이이며, 그 차이는 보이지 않는다: 한 사이클 짧은 스톨은 스테일 레지스터를 읽고 매번 전체 속도로, 폴트도 경고도 없이 틀린 숫자를 반환한다.

여기의 다른 모든 것은 그 문장을 테스트 가능하게 만들기 위해 존재한다. 어셈블러는 하나의 스톨을 의도적으로 줄인 프로그램을 만드는 것이다. 스케줄러는 모델이 다른 사람의 답을 평가하는 대신 답을 확정하도록 강제하는 것이다. 그리고 감사는 그 문장이 결여가 아니라 측정이 되는 지점이다: basalt는 NVIDIA가 cuBLAS, cuSOLVER, cuSPARSE, NPP 등에 포함해 배포하는 2,473개의 sm_120 cubin을 대상으로 삼았다.

왜 존재하지 않았는가, 이 분야의 말로. 가장 많이 사용되는 SASS 어셈블러는 자체 문서에서 "공식 지원 없이는 전체 프로그램의 엄격한 정확성을 검사하는 것 … [이] 거의 불가능하다. 따라서 프로그램의 정확성을 보장하는 것은 어셈블러의 매우 제한적인 도움만으로 사용자에게 맡겨진다."라고 말한다. SIP는 SASS 스케줄 자동 튜닝에 관해 "sass의 공식 의미론이 폐쇄 소스이기 때문에 GPU 네이티브 어셈블리 코드의 검증은 불가능하다."라고 말한다.

둘 다 의미론적(semantic) 정확성, 즉 커널이 의도한 대로 계산하는지에 관한 것이다. basalt는 그 질문에 답하지 않으며, 여기의 어떤 것도 그렇게 주장하지 않는다. basalt는 엄밀히 더 작은 질문에 답하며, 핵심은 그 더 작은 질문이 의미론 없이도 결정 가능하다는 것이다:

이 프로그램의 제어 비트가 자기 자신의 데이터 의존성을 모두 커버하는가?

그러려면 인코딩이 제공하는 의존성 구조와, 측정을 통해 실리콘이 내어주는 레이턴시 모델이 필요하다. 어느 쪽도 어떤 명령어가 무엇을 계산하는지 알 필요가 없다. 커널은 이 검사를 통과하면서도 여전히 잘못된 알고리즘일 수 있다. 다만 값이 도착하기 전에 레지스터를 읽는 일은 할 수 없다.

둘째, 다른 어떤 것도 벤더의 자체 바이트와 대조해 측정되지 않는다. basalt의 기준은 ptxas 출력이므로, 불일치는 반증되기 전까지 basalt의 버그다. basalt의 어셈블러는 컴파일러의 정확한 128비트를 재현해야 한다. 스케줄러는 컴파일러가 선택한 모든 제어 비트를 버리고 새 비트를 계산한 다음 GPU가 동일한 답을 계산하게 해야 한다.

그 모든 것에 적용되는 하나의 기준: 벤더와 정확히 일치하거나, 그 이유를 말하라.

그리고 스케줄러가 보통 조용히 넘어가는 부분: 정확성의 비용. basalt의 스케줄은 벤더의 발행 사이클의 1.05배를 사용하며, 1,323개의 커널 및 최적화 수준 쌍 중 111개에서 더 느리고 842개에서 더 저렴하며, 모든 비교 가능한 커널은 여전히 GPU에서 바이트 단위로 동일하다.

세 번째 행이 나머지 세 개를 바꾼 것이다. 코퍼스로 보정된 체커는 그 코퍼스에서는 실패할 수 없다: 컴파일러가 남기는 것이 관찰된 가장 좁은 간격은, 구성상, 측정된 바로 그 코드에 대한 바닥이다. 이 체커가 처음으로 다른 곳의 코드를 본 순간, 잘못된 픽셀을 한 번도 반환한 적 없는 JPEG 디코더에서 커널당 스물여섯 개의 위험을 보고했고, 6,593개 모두 basalt의 것이었다. 그것들을 고치자 0이 되었지만, 하나의 라이브러리에서의 0도 증거가 아니었다: 제외 집합을 세 개의 라이브러리와 520만 개의 명령어로 넓히자 곧바로 940으로 되돌아갔고, 처음 여덟 개에 더해 모델 오류 다섯 개를 더 찾아냈다. 열세 번의 수정, 그중 어느 것도 NVIDIA의 것이 아니었다. 그리고 24,311개의 배포 커널에서 다시 채굴한 요구사항은 229,567개의 관측치에 걸쳐 가드 프레디킷을 13 사이클에 두었는데, 이는 이 카드에서 프로그램을 의도적으로 깨뜨려 폴트 주입이 측정한 숫자다. 발견 32를 참조하라.

벤더보다 저렴하다는 것은 자랑할 만한 주장이 아니다. basalt는 모든 의존성을 해당 정확한 쌍에 대해 ptxas가 지금까지 남긴 것으로 관찰된 가장 좁은 간격으로 스케줄링하며, ptxas는 발행 레이턴시와 함께 레지스터 압박과 메모리를 균형 잡는 반면, 이것은 하나의 숫자만 최적화한다. 그것은 또한 눈으로 보고 곧바로 믿어지지 않았다: 비율이 처음 1.0 아래로 내려갔을 때 하드웨어 라운드 트립이 깨졌고, 그 숫자는 그것이 드러낸 버그가 고쳐진 뒤에야 유지되었다. 그 이유로 테스트 스위트에서는 그 비율이 양쪽에서 고정되어 있다.

중간 열이 핵심이다. 레이턴시 모델을 공유하는 체커와 스케줄러는 둘 다 틀린 상태에서도 서로 동의하므로, 어느 쪽도 상대방에 대한 증거가 될 수 없다. 오직 실리콘만이 그 논쟁에서 이해관계가 없다. 스케줄러를 손으로 작성한 커널 일곱 개에 실행했을 때 오랫동안 일곱 개 중 일곱 개가 통과했다. 그것을 삼백 개에 실행하자 마흔하나 개가 틀린 것으로 드러났고, 발견 사항의 모든 수정은 그 숫자가 움직이는 것을 지켜보는 데서 나왔다.

입력에도 같은 원칙이 적용된다. 스테일 읽기는 스테일 값과 새 값이 다를 때만 답을 바꾸므로, 하나의 바이트 패턴은 발견할 기회 한 번일 뿐이다. 모든 커널을 두 번째, 세 번째, 네 번째 패턴에 대해 실행하자 피연산자 모델이 처음부터 소스로 읽고 있던 캐리-아웃 조건자가 즉시 발견되었다. 그것은 그 시점까지 모든 검증을 통과했으며, 라운드 트립 자체도 포함했다.

동일한 원칙이 어셈블러가 무엇을 할 수 있는지를 결정하며, 어셈블러가 가진 두 숫자를 구분할 가치가 있다.

커버리지는 코퍼스의 99.9%와 배포 라이브러리 코드의 87.5%다. 정확성은 100%이며, 그것이 테스트로 고정되는 숫자다. 둘 사이의 차이는 basalt가 거부하는 명령어들로, 각각은 배치하지 못한 필드를 이름으로 밝힌다. 추측하는 도구는 올바른 텍스트로 역어셈블되면서 다른 것을 계산하는 워드를 생성함으로써 완전한 커버리지에 도달할 수 있기 때문이다. basalt는 59,760개의 코퍼스 명령어와 5,237,448개의 배포 명령어에 걸쳐 단 하나도 생성한 적이 없다.

그것은 확신에 차서 틀린 여덟 차례의 별도 시행 끝에야 그 지점에 도달했다:

• 즉치 형식의 인코딩에 레지스터 번호를 쓴 것,
• 유니폼 레지스터를 일반 레지스터와 상호 교환 가능한 것으로 취급한 것,
• 해당 형식을 수집해 온 커널의 분기 대상을 유지한 것,
• 반정밀도 부동소수점을 담는 필드에 정수 15를 넣은 것,
• 재사용 플래그로 밝혀진 비트에 피연산자를 쓴 것,
• 프로버가 부분적으로만 귀속시킨 필드에 써서 나머지가 여전히 이전 값을 인코딩하게 한 것,
• 레지스터 번호를 어느 레지스터 파일에 속하는지 선택하는 비트에 걸쳐 분산시킨 것,
• 레지스터 인덱스 상수 로드의 인덱스를 변위(displacement)로 읽은 것.

그 각각은 어셈블되고, 원래의 텍스트로 정확히 역어셈블되며, 다른 것을 계산하는 워드를 만들어냈다. 이 저장소의 나머지가 잡아내기 위해 존재하는 바로 그 실패다. 그래서 여덟 가지 모두 이제 필드가 실제로 무엇을 담는지 이름을 밝히는 사유와 함께 거부되며, 잘못된 바이트로 어셈블되는 명령어 수가 테이블의 숫자가 아니라 0으로 고정된 테스트인 이유다.

아홉 번째는 어셈블러가 자신이 생성하지 않은 기계어를 처음 가리켰을 때 나타났으며, 종류가 달랐다. c[0x0][UR4]는 기록된 형식이 숫자를 담는 곳에서 오프셋을 레지스터로 인덱싱하며, 인코더는 거부하는 대신 예외를 발생시켰다. 외부 입력에서의 크래시는 잘못된 판정보다 더 나쁘다. 호출자가 둘 다 얻지 못하기 때문이다.

지원 GPU

sm_120은 모델 번호가 아니다. 이것은 컨슈머 Blackwell 제품군 전체가 공유하는 컴퓨트 능력이며, 따라서 명령어 인코딩, 데이터베이스, 어셈블러, 체커는 그 안의 모든 카드에 적용된다:

ptxas는 또한 같은 제품군의 다른 칩인 sm_121을 대상으로 한다. basalt는 그 칩에서 실행된 적이 없으며 지원한다고 주장하지도 않는다. basalt가 말할 수 있는 것은 측정된 것이다: 컴파일러는 여기서 제공하는 여섯 가지 대상 모두에 대해 제어 워드를 포함해 바이트 단위로 동일한 코드를 생성하므로, 커널에 필요한 스케줄은 개별 부품의 속성이 아니라 아키텍처의 속성이다 (발견 28). 그것이 사실이 아니라면, NVIDIA 자신의 컴파일러가 그중 하나에 대해 안전하지 않은 스케줄을 생성하고 있을 것이다.

실리콘에서 측정된 모든 숫자는 단 하나의 물리적 카드에서 나온 것이며, 정확히 이름이 명시된다. "5070 Ti"만으로는 실행을 재현하기에 충분하지 않기 때문이다:

Cite the concept DOI, 10.5281/zenodo.22072811, rather than a version DOI or this URL. It resolves to the newest release, so it stays correct without ever being edited again. CITATION.cff carries it, so it is already in both forms above.

If you reuse the measured tables (src/basalt/data/) or reproduce a figure, cite the release they came from rather than main: the numbers are regenerated by scripts/verify_all.py at a specific commit, and a tag is what makes that reproducible.

Attribution is a licence term, not a courtesy. Apache-2.0 §4 requires that LICENSE and NOTICE travel with any redistribution or derivative work, and NOTICE carries the authorship and the clean-room statement. Forks, vendored copies and repackaged wheels all keep both files.

Author

Sunny Patel · sunnypatel.net · github.com/sunnypatell