Mọi người đều có thể đóng góp cho OpenXLA và chúng tôi trân trọng mọi đóng góp. Có một số cách để đóng góp, bao gồm:
Trả lời câu hỏi trên diễn đàn thảo luận của OpenXLA (openxla-discuss)
Cải thiện hoặc mở rộng tài liệu của OpenXLA
Đóng góp cho cơ sở mã của OpenXLA
Đóng góp theo bất kỳ cách nào nêu trên cho hệ sinh thái thư viện rộng lớn hơn được xây dựng trên OpenXLA
Dự án OpenXLA tuân thủ Nguyên tắc cộng đồng nguồn mở của Google.
Trước khi bắt đầu
Ký Thoả thuận cấp phép cho Contributor
Nội dung đóng góp cho dự án này phải kèm theo Thoả thuận cấp phép dành cho cộng tác viên (CLA). Bạn (hoặc chủ lao động của bạn) vẫn giữ bản quyền đối với nội dung bạn đóng góp; điều này chỉ đơn giản là cho phép chúng tôi sử dụng và phân phối lại nội dung bạn đóng góp trong dự án.
Nếu bạn hoặc người sử dụng lao động hiện tại của bạn đã ký CLA của Google (ngay cả khi đó là cho một dự án khác), thì có thể bạn không cần phải ký lại.
Hãy truy cập vào <https://cla.developers.google.com/> để xem các thoả thuận hiện tại hoặc ký một thoả thuận mới.
Xem Quy tắc ứng xử
Dự án này tuân theo Quy tắc ứng xử của TensorFlow.
Quy trình đóng góp
Hướng dẫn cho nhà phát triển
Để xem hướng dẫn về cách thiết lập môi trường phát triển cho OpenXLA, bao gồm cả việc lấy mã, tạo mã, chạy kiểm thử và gửi các thay đổi, vui lòng tham khảo Hướng dẫn dành cho nhà phát triển.
Hướng dẫn đóng góp
Cấu trúc của trình biên dịch bao gồm các thành phần sau.
Các lượt tối ưu hoá
Các lượt tối ưu hoá thực hiện các phép biến đổi trên HLO để nâng cao hiệu quả tính toán. Những biến đổi này trải dài từ các điểm cải tiến cấp cao, không phụ thuộc vào kiến trúc cho đến các điều chỉnh dành riêng cho phần cứng (ví dụ: đối với GPU NVIDIA).
Những gì chúng tôi thường chấp nhận:
- Các đường chuyền tổng quát trên nhiều khối lượng công việc và thể hiện tác động tích cực rõ ràng và đáng kể đến các điểm chuẩn hiệu suất.
Những nội dung chúng tôi thường từ chối:
- Các đường chuyền thực hiện hoạt động tối ưu hoá riêng biệt nhắm đến các mô hình cụ thể.
Thẻ và vé Fusion
Hợp nhất là một hoạt động tối ưu hoá quan trọng, kết hợp nhiều thao tác HLO thành một nhân duy nhất để giảm chi phí khởi chạy nhân và I/O bộ nhớ.
Bạn chỉ nên thêm tất cả các đường truyền hợp nhất vào quy trình hợp nhất, chứ không phải trước hoặc sau. Điều đó cũng có nghĩa là mô-đun HLO được tối ưu hoá trước không được chứa các chỉ dẫn hợp nhất. Nếu quá trình hợp nhất diễn ra sớm trong quy trình, thì quá trình này sẽ trở thành rào cản đối với các lượt tối ưu hoá. Nếu quá trình hợp nhất diễn ra muộn, thì chúng ta sẽ mất khả năng chọn và điều chỉnh phần phụ trợ cho hợp nhất được tạo.
Không được phép hợp nhất vào các lệnh gọi tuỳ chỉnh, tức là các lệnh gọi tuỳ chỉnh so khớp mẫu với nhà sản xuất/người tiêu dùng và viết lại chúng thành các lệnh gọi tuỳ chỉnh mới. Trong trường hợp đó, bạn nên thay thế bằng một đường chuyền hợp nhất thích hợp.
Chia tỷ lệ theo chiều ngang
Các đóng góp cho việc mở rộng quy mô theo chiều ngang bao gồm việc tối ưu hoá HLO, cải thiện mô hình chi phí, cập nhật thư viện và sửa đổi nhiều cơ sở hạ tầng. Do khó tái tạo được mức tăng hiệu suất và nhu cầu hạn chế đối với các cấu hình nhiều máy chủ nội bộ, chúng tôi tuân thủ các tiêu chí chấp nhận nghiêm ngặt:
Chúng tôi ưu tiên những thay đổi ít xâm nhập và có rủi ro thấp.
Những gì chúng tôi thường chấp nhận:
Cập nhật các thư viện xử lý hoạt động giao tiếp giữa các GPU hoặc giữa các máy chủ lưu trữ.
Cập nhật bảng hiệu suất cho các nền tảng mới.
Những nội dung chúng tôi thường từ chối:
HLO viết lại hoặc thay đổi thời gian chạy phù hợp với một mô hình cụ thể.
Các thay đổi về cơ sở hạ tầng làm xuất hiện các cờ mới, nợ kỹ thuật hoặc hồi quy.
Phần phụ trợ và tính năng tự động điều chỉnh
Các phần phụ trợ cho các thao tác không lồng nhau (ví dụ: lệnh gọi và hợp nhất tuỳ chỉnh) phải triển khai giao diện CodegenBackend.
Giao diện này là cần thiết để cho phép lựa chọn phụ trợ tối ưu, vì giao diện này cung cấp các phương thức để đưa các tham số cho hướng dẫn HLO nhất định vào không gian tìm kiếm của trình điều chỉnh tự động.
// 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);
Thời gian chạy
Kết quả cuối cùng của quy trình biên dịch XLA là một chuỗi thunk có thể được chuyển đổi tuần tự.
Tất cả các loại thunk mới đều phải có thể chuyển đổi tuần tự, tức là GpuCompiler hoặc CpuCompiler phải có thể biên dịch chương trình, chuyển đổi tuần tự chương trình đó để sau này trình chạy XLA có thể tải và thực thi chương trình. Điều đó có nghĩa là không được có con trỏ đến HloInstruction hoặc đến các phần khác của trình biên dịch hoặc StreamExecutor.
Tiêu chuẩn về mã
Kiểu mã hoá: Chúng tôi tuân thủ hướng dẫn về kiểu mã của Google. Cụ thể, hãy xem hướng dẫn về C/C++ và Python. Tất cả mã được gửi phải tuân thủ nghiêm ngặt các hướng dẫn về kiểu này.
Thay đổi nhỏ: Chúng tôi tuân theo các phương pháp kỹ thuật của Google. Cụ thể, vui lòng tham khảo hướng dẫn về cách viết các thay đổi nhỏ gọn. Làm như vậy sẽ giúp tăng đáng kể tốc độ hợp nhất mã của bạn do khả năng xem xét được cải thiện và giảm khả năng xảy ra các tác dụng phụ không mong muốn của thay đổi. Ngay cả khi có một thay đổi lớn, bạn vẫn có thể áp dụng nhiều chiến lược để chia thay đổi đó thành nhiều thay đổi nhỏ hơn.
Phạm vi kiểm thử: Tất cả các thay đổi phải bao gồm các kiểm thử đơn vị thích hợp. Các kiểm thử đơn vị không được phụ thuộc vào thời gian của phần cứng cụ thể (CPU, GPU, v.v.) và phải sử dụng nhiều đối tượng mô phỏng và đối tượng giả để thực hiện các kiểm thử có tính xác định và tập trung. Những thay đổi nhằm mở rộng mã hiện có (hiện khó kiểm thử) cần có những điểm cải tiến phù hợp để tăng khả năng kiểm thử.
Tất cả các thay đổi đều phải có kết quả đo điểm chuẩn phù hợp trong tiêu đề thay đổi để đảm bảo mọi người hiểu rõ lợi ích.
Khi nghi ngờ về các quy ước trong mã, bạn nên kiểm tra mã hiện có và cố gắng tuân theo các mẫu đã có trong OpenXLA.
Quy trình xem xét
Tất cả nội dung gửi, kể cả nội dung do thành viên dự án gửi, đều phải được xem xét. Chúng tôi sử dụng yêu cầu kéo GitHub cho mục đích này. Hãy tham khảo GitHub Help để biết thêm thông tin về cách sử dụng yêu cầu kéo.
Mã phải tuân thủ tất cả các tiêu chuẩn nêu trên trước khi được xem xét. Đây không phải là các trường không bắt buộc và người gửi phải đảm bảo mã của họ tuân thủ trước khi yêu cầu xem xét để đảm bảo các thay đổi được chấp nhận kịp thời.
Tất cả các bài kiểm thử đều phải đạt. Nếu bạn thấy một bài kiểm thử bị lỗi và vấn đề không liên quan đến môi trường bản dựng hoặc các thay đổi của bạn, vui lòng liên hệ với người duy trì.
Cố gắng tránh tình trạng phạm vi bị mở rộng trong quá trình xem xét. Đây là trách nhiệm của cả người gửi và người đánh giá. Nếu một thay đổi bắt đầu trở nên quá lớn, hãy cân nhắc chia thay đổi đó thành nhiều thay đổi.
Trước khi được hợp nhất, thay đổi sẽ trải qua quá trình kiểm thử nội bộ bằng mã nội bộ của Google và các nhà cung cấp phần cứng khác. Điều này có thể làm tăng thêm các bước cho quy trình xem xét nếu có lỗi trong các thử nghiệm nội bộ mà CI công khai của chúng tôi không phát hiện được. Nhân viên Google xem xét thay đổi của bạn sẽ thông báo mọi lỗi kiểm thử nội bộ và mô tả những điểm cần khắc phục.
Câu hỏi thường gặp
"Thay đổi về cơ sở hạ tầng này không liên quan đến yêu cầu kéo của tôi. Tại sao tôi nên làm việc này?"
Nhóm XLA không có nhóm cơ sở hạ tầng chuyên trách, vì vậy, tất cả chúng ta đều phải xây dựng các thư viện trợ giúp và tránh nợ kỹ thuật. Chúng tôi coi đây là một phần thường xuyên của việc thay đổi XLA và mọi người đều phải tham gia. Chúng ta thường xây dựng cơ sở hạ tầng khi cần thiết trong quá trình viết mã.
Người đánh giá XLA có thể yêu cầu bạn xây dựng một số cơ sở hạ tầng (hoặc thực hiện một thay đổi lớn đối với một PR) cùng với một PR mà bạn đã viết. Yêu cầu này có thể không cần thiết hoặc không liên quan đến thay đổi mà bạn đang cố gắng thực hiện. Điều này có thể là do sự khác biệt giữa kỳ vọng của bạn về lượng cơ sở hạ tầng cần xây dựng và kỳ vọng của người đánh giá về lượng cơ sở hạ tầng đó.
Bạn có thể không đáp ứng được kỳ vọng! Điều đó là bình thường khi bạn mới tham gia một dự án (đôi khi ngay cả những người có kinh nghiệm như chúng tôi cũng gặp phải). Có thể những dự án mà bạn từng tham gia có những kỳ vọng khác nhau. Điều đó cũng không sao và nằm trong dự kiến! Điều này không có nghĩa là một trong hai dự án này có cách tiếp cận sai, mà chỉ là chúng khác nhau. Bạn nên xem xét các yêu cầu về cơ sở hạ tầng cùng với tất cả các nhận xét đánh giá khác như một cơ hội để tìm hiểu những gì chúng tôi mong đợi ở dự án này.
"Tôi có thể giải quyết bình luận của bạn trong một yêu cầu hợp nhất trong tương lai không?"
Một câu hỏi thường gặp liên quan đến các yêu cầu về cơ sở hạ tầng (hoặc các yêu cầu lớn khác) trong PR là liệu thay đổi có phải được thực hiện trong PR ban đầu hay không, hoặc liệu thay đổi có thể được thực hiện dưới dạng một yêu cầu tiếp theo trong PR sau này hay không.
Nhìn chung, XLA không cho phép tác giả PR giải quyết các bình luận đánh giá bằng một PR tiếp theo. Khi người đánh giá quyết định rằng có điều gì đó cần được giải quyết trong một PR nhất định, chúng tôi thường mong đợi tác giả giải quyết vấn đề đó trong PR đó, ngay cả khi những gì được yêu cầu là một thay đổi lớn. Tiêu chuẩn này áp dụng cả bên ngoài và bên trong Google.
XLA áp dụng phương pháp này vì một số lý do.
Niềm tin: Có được niềm tin của người đánh giá là một yếu tố quan trọng. Trong một dự án nguồn mở, người đóng góp có thể xuất hiện hoặc biến mất tuỳ ý. Sau khi chúng tôi phê duyệt một yêu cầu kéo, người đánh giá không có cách nào để đảm bảo rằng mọi việc cần làm tiếp theo như đã hứa đều được thực hiện.
Tác động đến các nhà phát triển khác: Nếu bạn đã gửi một yêu cầu hợp nhất liên quan đến một phần cụ thể của XLA, thì có khả năng những người khác cũng đang xem xét phần đó. Nếu chúng ta chấp nhận nợ kỹ thuật trong yêu cầu kéo của bạn, thì mọi người xem tệp này sẽ bị ảnh hưởng bởi khoản nợ này cho đến khi yêu cầu tiếp theo được gửi.
Khả năng của người đánh giá: Việc trì hoãn một thay đổi để theo dõi sẽ gây ra nhiều chi phí cho những người đánh giá vốn đã quá tải của chúng tôi. Người đánh giá có thể quên nội dung của PR đầu tiên trong khi chờ PR tiếp theo, khiến lần đánh giá tiếp theo trở nên khó khăn hơn. Ngoài ra, người đánh giá sẽ phải theo dõi các bước tiếp theo dự kiến, đảm bảo rằng các bước đó thực sự diễn ra. Nếu có thể thực hiện thay đổi sao cho thay đổi đó thực sự độc lập với PR ban đầu để một người đánh giá khác có thể xem xét, thì băng thông sẽ ít gặp vấn đề hơn. Theo kinh nghiệm của chúng tôi, trường hợp này hiếm khi xảy ra.