Làm thế nào để tận dụng tối đa SIMD trong OpenCL?

Question

Trong optimization guide of Beignet, an open source implementation of OpenCL targeting Intel GPUs

làm việc nhóm Kích thước nên lớn hơn 16 và là bội số của 16.

Như hai làn đường SIMD có thể trên Gen 8 hoặc 16. Để không lãng phí SIMD làn xe, chúng ta cần tuân theo quy tắc này.

Cũng đề cập trong Compute Architecture of Intel Processor Graphics Gen7.5:

Đối với sản phẩm Gen7.5 dựa, mỗi EU có bảy đề với tổng số 28 Kbytes file thanh ghi mục đích chung (GRF).

...

Về kiến ​​trúc tính toán Gen7.5, hầu hết các mô hình lập trình SPMD dụng này sinh mã phong cách và thực hiện xử lý EU. Có hiệu lực, mỗi cá thể hạt nhân SPMD xuất hiện để thực thi serially và độc lập trong làn SIMD riêng của mình.

Trong thực tế, mỗi chuỗi thực hiện số lượng phiên bản hạt nhân SIMD-Chiều rộng> đồng thời. Như vậy cho một biên dịch SIMD-16 của một tính toán hạt nhân, nó có thể cho SIMD-16 x 7 đề = 112 trường hợp kernel được thực hiện đồng thời trên một EU duy nhất. Tương tự, đối với SIMD-32 x 7 luồng = 224 phiên bản hạt nhân thực hiện đồng thời trên một đơn EU.

Nếu tôi hiểu chính xác, sử dụng SIMD-16 x 7 threads = 112 kernel instances làm ví dụ, để chạy 224 chủ đề trên một EU, kích thước nhóm công việc cần là 16. Sau đó trình biên dịch OpenCL sẽ gấp 16 phiên bản kernel thành 16 luồng SIMD thread, và làm điều này 7 lần trên 7 nhóm làm việc, và chạy chúng trên một EU duy nhất?

Câu hỏi 1: Tôi có đúng cho đến đây không?

Tuy nhiên OpenCL spec cũng cung cấp các loại dữ liệu vectơ. Vì vậy, nó khả thi để tận dụng tối đa các nguồn tài nguyên máy tính SIMD-16 trong một EU bằng cách lập trình SIMD thông thường (như trong NEON và SSE).

Câu hỏi 2: Nếu trường hợp này xảy ra, sử dụng loại dữ liệu vector-16 đã sử dụng rõ ràng tài nguyên SIMD-16, do đó loại bỏ giới hạn ít nhất 16 mục cho mỗi nhóm làm việc. Đây có phải là trường hợp không?

Câu hỏi 3: Nếu tất cả ở trên là đúng sự thật, sau đó làm thế nào để tiếp cận hai so sánh với nhau: 1) 112 bài gấp vào 7 SIMD-16 chủ đề bởi trình biên dịch OpenCL; 2) 7 chuỗi gốc được mã hóa để sử dụng rõ ràng loại dữ liệu vector-16 và các hoạt động SIMD-16?

Answer 1

1. Hầu như. Bạn đang đưa ra các giả định rằng có một luồng cho mỗi nhóm làm việc (luồng B trong ngữ cảnh này là cái mà CUDA gọi là "sóng".Trong GPU Intel nói một mục công việc là một kênh SIMD của một chủ đề GPU). Nếu không có các nhóm con, không có cách nào để buộc một kích thước nhóm làm việc chính xác là một luồng. Ví dụ, nếu bạn chọn kích thước WG là 16, trình biên dịch vẫn còn miễn phí để biên dịch SIMD8 và lây lan nó giữa hai luồng SIMD8. Hãy nhớ rằng trình biên dịch chọn chiều rộng SIMD trước khi kích thước WG được biết đến (clCompileProgram trước clEnqueueNDRange). subgroups extension có thể cho phép bạn ép chiều rộng SIMD, nhưng chắc chắn không được triển khai trên GEN7.5.

2. Loại vectơ OpenCL là một bước vectơ rõ ràng tùy chọn ở trên cùng của vectơ ngầm hóa đã xảy ra tự động. Bạn có sử dụng float16 chẳng hạn. Mỗi hạng mục công việc sẽ được xử lý 16 nổi, nhưng trình biên dịch vẫn sẽ biên dịch ít nhất là SIMD8. Do đó mỗi thread GPU sẽ được xử lý (8 * 16) nổi (song song mặc dù). Đó có thể là một chút quá mức cần thiết. Lý tưởng nhất là chúng tôi không muốn phải minh họa rõ ràng CL của mình bằng cách sử dụng các loại vectơ OpenCL rõ ràng. Nhưng đôi khi có thể hữu ích nếu hạt nhân không làm đủ công việc (hạt nhân quá ngắn có thể xấu). Một nơi nào đó nó nói float4 là một nguyên tắc tốt.

3. Tôi nghĩ bạn có nghĩa là 112 mục công việc? Bởi chủ đề ban đầu bạn có nghĩa là chủ đề CPU hoặc chủ đề GPU?

   • Nếu bạn có nghĩa là chủ đề CPU, các đối số thông thường về GPU sẽ được áp dụng. GPU là tốt khi chương trình của bạn không phân kỳ nhiều (tất cả các trường hợp có đường dẫn tương tự) và bạn sử dụng dữ liệu đủ thời gian để giảm thiểu chi phí chuyển nó đến và đi từ GPU (mật độ số học).
   • Nếu bạn có nghĩa là các chủ đề GPU (các máy ghi âm SIM SIMD8 hoặc SIMD16). Không có cách nào để hiển thị chủ đề GPU một cách rõ ràng tại thời điểm này (EDIT xem subgroups extension (không có trên GEN7.5)). Nếu bạn có thể, nó sẽ là một thương mại tương tự với ngôn ngữ lắp ráp. Công việc này khó hơn, và trình biên dịch đôi khi chỉ làm tốt hơn, nhưng khi bạn giải quyết một vấn đề cụ thể và có kiến ​​thức về miền tốt hơn, bạn có thể làm tốt hơn với đủ nỗ lực lập trình (cho đến khi thay đổi phần cứng và giả định của chương trình thông minh của bạn bị vô hiệu.)