[Triton] gfx1250 Shared Memory 크기 정확하게 반환하기
PR 링크: triton-lang/triton#8517 상태: Merged | 변경: +9 / -2
들어가며
Triton은 다양한 GPU 아키텍처를 지원하는 컴파일러다. 각 GPU마다 shared memory 크기가 다르기 때문에, 타겟 정보(TargetInfo)에서 정확한 값을 반환해야 올바른 코드가 생성된다. AMD의 새로운 gfx1250 아키텍처는 320KB의 shared memory를 제공하지만, 기존 코드에서는 이를 처리하지 못했다.
핵심 코드 분석
Before
int TargetInfo::getSharedMemorySize() const {
int kbytes = getISAFamily() == ISAFamily::CDNA4 ? 160 : 64;
return kbytes * 1024;
}
삼항 연산자로 CDNA4와 나머지만 구분했기 때문에, gfx1250이 추가되면 기본값 64KB를 반환하는 문제가 있었다.
After
int TargetInfo::getSharedMemorySize() const {
switch (getISAFamily()) {
case ISAFamily::GFX1250:
return 320 * 1024;
case ISAFamily::CDNA4:
return 160 * 1024;
default:
return 64 * 1024;
}
}
switch 문으로 변경하여 각 아키텍처별 shared memory 크기를 명확하게 분리했다.
왜 이게 좋은가
- 확장성: 새로운 아키텍처가 추가될 때 case 하나만 넣으면 된다
- 가독성: 각 아키텍처의 shared memory 크기가 한눈에 보인다
- 정확성: gfx1250에서 320KB shared memory를 올바르게 활용할 수 있게 된다
정리
작은 변경이지만, GPU 컴파일러에서 하드웨어 스펙을 정확히 반영하는 것은 매우 중요하다. 잘못된 shared memory 크기는 커널 실행 실패나 성능 저하로 직결된다. switch 패턴은 이런 종류의 다중 분기 처리에 가장 적합한 방법이다.
참고 자료
이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 코드 분석 내용은 실제 PR diff를 기반으로 합니다.
관련 포스트
- [triton] AMD: padded shared layout을 더 작은 block size에도 적용하여 bank conflict 제거
- [triton] AMD TDM의 Partition-Aware 분할 및 다중 Intrinsic 지원
- [triton] AMD GFX9 Async Copy에서 Shared Memory 순서 버그 수정
- [triton] AMD Async Wait Count에서 Warp Free Variable 및 Register Zero Base 버그 수정
- [triton] AMD 백엔드에 Concurrency Sanitizer(ConSan) 지원 추가
PR Analysis 의 다른글
- 이전글 [pydantic-ai] GoogleProvider에 http_client 옵션 추가 및 Vertex AI API 키 지원
- 현재글 : [Triton] gfx1250 Shared Memory 크기 정확하게 반환하기
- 다음글 [Grafana Loki] 쿼리 옵티마이저를 bottom-up에서 top-down 방식으로 리팩터링하여 중복 작업 제거
댓글