현재 통일된 바인딩 코드 사용, 바인딩이 수정이 될 경우는?

바인딩을 수정하게 되는 대표 상황들

1)  Tensor 제약이 깨질 때

지금은 CUDA + contiguous + (f16  / f32) 만 받음

• 비연속 ( non-contig ) stride 지원
  • 예 : view / transpose 그대로 커널이 받아야 함
  • 바인딩에서 TensorDesc.stride 를 실제 stride 로 채우거나, noncontig 허용 정책을 바꿔야 함
• 다른 dtype 지원
  • int 8, bf 16, fp 8 같은 dtype
  • to_aicf_dtype() 확장 + 검사 정책 변경 필요
• device / align / pointer info 추가
  • 예: alignment 보장, vectorized load / store 요구
  • TensorDesc.aligment 계산/ 추론을 바인딩에서 넣어주는 것이 깔끔

 

2) attrs ( dict ) 가 부족해질 때 (가장 흔함)

현재 attrs 는 bool / int / float 만 됨

• 문자열 / enum 필요
  • 예 : activation = gelu, layout = NHWC
  • 문자열을 그대로 넘기면 async lifetime 문제가 생기니 보통은 enum / int 로 변환, 그 변환이 바인딩 쪽에 생김
• 리스트 / 튜플 / shape 같은 구조화된 값 필요
  • 예 : pads = [1,1,1,1], stride = [2,2], dilations = [1,1] 
  • 현재 AttrPack 은 스칼라만이라 구조체 전달이 필요해짐
  • 해결 패턴
    • AttrPack 에 array 타입을 추가하거나
    • op 별 AttrStruct 를 만들고 바인딩에서 파싱해서 attr_ptr 로 넘김
• 정밀한 타입 필요

 

3) stream 정책이 바뀔 때

지금은 stream = nullptr 로 backend 가 알아서 current stream

• Python 에서 torch current stream 을 진짜로 넘겨야 할 때
• 외부에서 stream 을 인자로 받는 API 로 확장

 

4) workspace (임시 메모리) 가 필요해질 때

현재는 workspace = 0 고정

• softmax, reduction, conv, attention 같은 건 workspace 가 흔함
• 그 때는 바인딩에서
  • query_workspace() 호출
  • torch tensor 로 workspace 버퍼 할당
  • 그 포인터를 launch 에 전달, 

이 로직이 들어가면서 바인딩이 커짐

 

5) 상태가 필요한 op 가 생길 때

대표적으로 RNG 가 들어가는 연산들