1. 현재까지 수정 핵심 정리
A. Op - Kernel - Dispatch 경로가 완전히 규격화됨
Python op_call
→ TensorDesc / AttrPack (binding)
→ dispatch_v0
→ KernelRegistry
→ KernelVariant (supported / priority)
→ launcher.cu
→ kernel.cu
수정을 통해 이 경로가 모든 op 에 대해 동일한 규칙을 따르게 됐음
B. Opkind / registery 구조가 codegen 친화적으로 정리됨
OpKind
enum class OpKind : int {
EltwiseAdd = 0,
EltwiseRelu = 1,
Gemm = 2,
_Count = 3
};
register_all.cpp
현재 구조는 자동 패치가 가능한 형태
{
auto v = make_add_f32_variant();
R.register_kernel(OpKind::EltwiseAdd, v);
}
- make_<op>_<dtype>_variant() 만 생성하면
- register 블록을 기계적으로 추가 가능
c. TensorDesc / valiate / launcher 템플릿 통일의 의미
이전
- op 마다 validate 로직 다름
- supported / launch 조건 불일치 가능
- ndim() / r.ndim 혼재
지금
- rank = r.rank 로 canonical
- valiate 는 shim preset 사용
- launcher 는 항상
- variant_check
- supported = check
- launch = check + kernel
이 상태는 자동 생성해도 안전한 구조
D. Python binding 이 이제 고정 인터페이스가 됨
binding 이 op 별로 바뀌지 않음, 새 op 추가해도 Python 코드는 안 건드려도 됨
'AI Compiler framework' 카테고리의 다른 글
| Trainer 의 역할 정의 ( AICF Framework - Execution Orchestrator ) 학습을 위해서가 아닌 실행을 고정하고 성능을 관찰하기 위해 등장한 구조 (0) | 2025.12.21 |
|---|---|
| 현재 상황 및 개선해야 할 사항들에 대해 ( Trainer, Kernel, IR 표현 등등... ) (0) | 2025.12.21 |
| 현재 통일된 바인딩 코드 사용, 바인딩이 수정이 될 경우는? (0) | 2025.12.20 |
| AICF Python Binding - Plan A (Unified op_call) 설계 문서 (0) | 2025.12.20 |
| Python <-> CUDA Ops Binding 설계 및 pyd 모듈 생성 과정 (0) | 2025.12.19 |