누구나 OpenXLA에 기여할 수 있으며 Google은 모든 사용자의 기여를 소중히 여깁니다. 다음과 같은 여러 방법으로 참여할 수 있습니다.
OpenXLA 토론 포럼 (openxla-discuss)에서 질문에 답변
OpenXLA 문서 개선 또는 확장
OpenXLA 코드베이스에 기여
OpenXLA를 기반으로 빌드된 광범위한 라이브러리 생태계에 위의 방법 중 하나로 기여
OpenXLA 프로젝트는 Google의 오픈소스 커뮤니티 가이드라인을 따릅니다.
시작하기 전에
기여자 라이선스 계약에 서명
이 프로젝트에 대한 기여에는 기여자 라이선스 계약 (CLA)이 포함되어야 합니다. 귀하 (또는 귀하의 고용주)는 귀하의 기여에 대한 저작권을 보유합니다. 이는 Google이 프로젝트의 일부로 귀하의 기여를 사용하고 재배포할 수 있는 권한을 부여하는 것일 뿐입니다.
귀하 또는 현재 고용주가 이미 Google CLA에 서명한 경우 (다른 프로젝트를 위한 경우도 포함) 다시 서명하지 않아도 됩니다.
<https://cla.developers.google.com/>에서 현재 계약을 확인하거나 새 계약에 서명하세요.
윤리 강령 검토
이 프로젝트는 Tensorflow의 윤리 강령을 따릅니다.
기여 절차
개발자 가이드
코드를 가져오고, 빌드하고, 테스트를 실행하고, 변경사항을 제출하는 등 OpenXLA 개발 환경을 설정하는 방법에 관한 가이드는 개발자 가이드를 참고하세요.
기여 가이드
컴파일러 아키텍처는 다음 구성요소로 구성됩니다.
최적화 패스
최적화 패스는 HLO에서 변환을 실행하여 계산 효율성을 향상합니다. 이러한 변환은 아키텍처에 구애받지 않는 상위 수준 개선사항부터 하드웨어별 조정 (예: NVIDIA GPU용)까지 다양합니다.
일반적으로 허용되는 경우:
- 여러 워크로드에 걸쳐 일반화되고 성능 벤치마크에 명확하고 상당한 긍정적 영향을 미치는 패스
일반적으로 거부되는 항목:
- 특정 모델을 타겟팅하는 고유한 최적화를 실행하는 패스입니다.
Fusion 패스
퓨전은 여러 HLO 작업을 단일 커널로 결합하여 메모리 I/O와 커널 실행 오버헤드를 줄이는 중요한 최적화입니다.
모든 병합 패스는 병합 파이프라인에만 추가해야 합니다(전후 아님). 즉, 사전 최적화된 HLO 모듈에는 융합 명령어가 포함되지 않아야 합니다. 융합이 파이프라인 초기에 형성되면 최적화 패스의 장벽이 됩니다. 융합이 늦게 형성되면 생성된 융합의 백엔드를 선택하고 조정하는 기능이 손실됩니다.
커스텀 호출로의 병합, 즉 프로듀서/컨슈머를 사용하여 커스텀 호출의 패턴을 일치시키고 이를 새로운 커스텀 호출로 다시 작성하는 것은 허용되지 않습니다. 이 경우 적절한 융합 패스로 대체해야 합니다.
수평 확장
수평 확장 기여에는 HLO 최적화, 비용 모델 개선, 라이브러리 업데이트, 다양한 인프라 수정이 포함됩니다. 성능 향상을 재현하기 어렵고 내부적으로 멀티 호스트 구성이 필요한 경우가 제한적이므로 엄격한 승인 기준을 준수합니다.
위험이 낮은 최소 침습적 변경사항이 우선적으로 적용됩니다.
일반적으로 허용되는 경우:
GPU 간 또는 호스트 간 통신을 처리하는 라이브러리 업데이트
새 플랫폼의 실적 표 업데이트
일반적으로 거부되는 항목:
특정 모델에 맞게 조정된 HLO 재작성 또는 런타임 변경사항
새 플래그, 기술 부채 또는 회귀를 도입하는 인프라 변경사항
백엔드 및 자동 조정
중첩되지 않은 작업(예: 맞춤 호출 및 융합)의 백엔드는 CodegenBackend 인터페이스를 구현해야 합니다.
이 인터페이스는 최적의 백엔드 선택을 지원하는 데 필요합니다. 주어진 HLO 명령어의 매개변수를 자동 튜너의 검색 공간에 포함하는 메서드를 제공하기 때문입니다.
// Returns all supported configs for the given HLO instruction.
virtual absl::StatusOr<std::vector<std::unique_ptr<BackendConfig>>>
GetSupportedConfigs(const HloInstruction& instr);
// Returns a default config for the given HLO instruction.
virtual absl::StatusOr<std::unique_ptr<BackendConfig>> GetDefaultConfig(
const HloInstruction& instr);
런타임
XLA 컴파일 파이프라인의 최종 결과는 직렬화할 수 있는 썽크 시퀀스입니다.
새로운 썽크 유형은 모두 직렬화 가능해야 합니다. 즉, GpuCompiler 또는 CpuCompiler가 프로그램을 컴파일하고 직렬화하여 나중에 XLA 러너가 프로그램을 로드하고 실행할 수 있어야 합니다. 즉, HloInstruction 또는 컴파일러나 StreamExecutor의 다른 부분을 가리키는 포인터가 없어야 합니다.
코드 표준
코딩 스타일: Google 코드 스타일 가이드를 따릅니다. 특히 C/C++ 및 Python 가이드를 참고하세요. 제출된 모든 코드는 이러한 스타일 가이드를 엄격하게 준수해야 합니다.
변경사항 압축: Google의 엔지니어링 관행을 따릅니다. 특히 간결한 변경사항 작성 가이드를 준수하세요. 이렇게 하면 검토 가능성이 개선되고 의도치 않은 변경의 부작용 가능성이 줄어들어 코드가 병합되는 속도가 크게 빨라집니다. 대규모 변경이 있더라도 이를 더 점진적인 변경으로 나누는 전략은 많습니다.
테스트 범위: 모든 변경사항에는 적절한 단위 테스트가 포함되어야 합니다. 단위 테스트는 특정 하드웨어 (CPU, GPU 등) 타이밍에 종속되어서는 안 되며 결정적이고 집중적인 테스트를 위해 모의 객체와 가짜 객체를 자유롭게 사용해야 합니다. 현재 테스트하기 어려운 기존 코드를 확장하려는 변경사항은 테스트 가능성을 적절하게 개선해야 합니다.
모든 변경사항에는 혜택을 명확하게 이해할 수 있도록 변경사항 제목에 적절한 벤치마크 결과도 포함되어야 합니다.
코드 내 규칙이 확실하지 않은 경우 항상 기존 코드를 검사하고 OpenXLA에 이미 있는 패턴을 따르는 것이 좋습니다.
검토 절차
프로젝트 회원의 제출을 포함한 모든 제출에는 검토가 필요합니다. 이 목적을 위해 GitHub pull 요청을 사용합니다. pull 요청 사용에 관한 자세한 내용은 GitHub 도움말을 참고하세요.
코드는 검토 전에 위에 나열된 모든 표준을 따라야 합니다. 이는 선택사항이 아니며 변경사항이 적시에 승인되도록 제출자가 검토를 요청하기 전에 코드가 준수하는지 확인하는 것이 중요합니다.
모든 테스트를 통과해야 합니다. 테스트가 중단되었고 문제가 빌드 환경이나 변경사항과 관련이 없는 경우 유지관리자에게 문의하세요.
검토 과정에서 범위 확대를 피하세요. 이는 제출자와 검토자 모두의 책임입니다. 변경사항이 너무 커지기 시작하면 여러 변경사항으로 나누는 것이 좋습니다.
변경사항이 병합되기 전에 Google 및 기타 하드웨어 공급업체의 내부 코드를 사용하는 내부 테스트를 거칩니다. 공개 CI에서 포착하지 못한 내부 테스트 실패가 있는 경우 검토 프로세스에 추가 단계가 추가될 수 있습니다. 변경사항을 검토하는 Google 직원이 내부 테스트 실패를 전달하고 수정해야 할 사항을 설명합니다.
자주 묻는 질문(FAQ)
'이 인프라 변경사항은 내 PR과 관련이 없습니다. 왜 그렇게 해야 하나요?'
XLA팀에는 전담 인프라팀이 없으므로 헬퍼 라이브러리를 빌드하고 기술 부채를 피하는 것은 모두의 몫입니다. 이는 XLA 변경의 정기적인 부분으로 간주되며 모든 사람이 참여해야 합니다. 일반적으로 코드를 작성할 때 필요에 따라 인프라를 빌드합니다.
XLA 검토자는 작성한 PR과 함께 일부 인프라를 빌드하거나 PR을 크게 변경하도록 요청할 수 있습니다. 이 요청이 불필요하거나 적용하려는 변경사항과 관련이 없는 것처럼 보일 수 있습니다. 이는 빌드해야 하는 인프라의 양에 대한 개발자의 기대치와 검토자의 기대치가 일치하지 않기 때문일 수 있습니다.
기대에 미치지 못해도 괜찮습니다. 프로젝트를 처음 접하는 경우 이러한 상황이 발생할 수 있습니다(숙련된 사용자에게도 가끔 발생함). 이전에 작업한 프로젝트의 기대치와 다를 수 있습니다. 이것도 괜찮고 예상되는 동작입니다. 이러한 프로젝트 중 어느 하나가 잘못된 접근 방식을 사용한다는 의미는 아닙니다. 단지 다를 뿐입니다. 인프라 요청을 다른 모든 검토 의견과 함께 이 프로젝트에서 Google이 기대하는 바를 배울 기회로 삼으시기 바랍니다.
"향후 PR에서 댓글을 처리해도 될까요?"
PR의 인프라 요청 (또는 기타 대규모 요청)과 관련해 자주 묻는 질문은 변경사항을 원래 PR에서 해야 하는지 아니면 향후 PR에서 후속 조치로 할 수 있는지입니다.
일반적으로 XLA에서는 PR 작성자가 후속 PR로 검토 의견을 해결하는 것을 허용하지 않습니다. 검토자가 특정 PR에서 해결해야 할 사항이 있다고 판단하는 경우, 요청된 사항이 큰 변경사항이라 하더라도 일반적으로 작성자가 해당 PR에서 이를 해결해야 합니다. 이 표준은 외부뿐만 아니라 Google 내부에도 적용됩니다.
XLA가 이 접근 방식을 취하는 데는 몇 가지 이유가 있습니다.
신뢰: 검토자의 신뢰를 얻는 것이 핵심 요소입니다. 오픈소스 프로젝트에서는 기여자가 원하는 대로 나타나거나 사라질 수 있습니다. PR이 승인된 후에는 검토자가 약속된 후속 조치가 실제로 완료되었는지 확인할 방법이 없습니다.
다른 개발자에게 미치는 영향: XLA의 특정 부분을 수정하는 PR을 보낸 경우 다른 사용자가 동일한 부분을 살펴보고 있을 가능성이 높습니다. PR에서 기술 부채를 수락하면 후속 조치가 제출될 때까지 이 파일을 보는 모든 사람이 이 부채의 영향을 받습니다.
검토자 대역폭: 변경사항을 후속 조치로 연기하면 이미 과부하 상태인 검토자에게 여러 비용이 부과됩니다. 후속 조치를 기다리는 동안 검토자는 첫 번째 PR의 내용을 잊어버릴 수 있으므로 다음 검토가 더 어려워집니다. 또한 검토자는 예상되는 후속 조치를 추적하여 실제로 이루어지도록 해야 합니다. 다른 검토자가 검토할 수 있도록 원래 PR과 완전히 직교하도록 변경할 수 있다면 대역폭은 문제가 되지 않습니다. Google의 경험에 따르면 이러한 경우는 드뭅니다.