Thực hiện các thuật toán thông qua các shader tính toán so với shader đường ống


10

Với tính năng sẵn sàng của các trình đổ bóng tính toán cho cả DirectX và OpenGL, giờ đây có thể thực hiện nhiều thuật toán mà không cần thông qua đường ống rasterization và thay vào đó sử dụng tính toán mục đích chung trên GPU để giải quyết vấn đề.

Đối với một số thuật toán, điều này dường như trở thành giải pháp chính tắc trực quan bởi vì chúng vốn không phải là rasterization, và các shader dựa trên rasterization dường như là một cách giải quyết để khai thác sức mạnh của GPU (ví dụ đơn giản: tạo ra kết cấu nhiễu. ).

Đưa ra một thuật toán có thể được thực hiện theo cả hai cách, liệu có lợi ích hiệu suất chung (tiềm năng) so với việc sử dụng các shader tính toán so với đi theo lộ trình thông thường? Có những nhược điểm mà chúng ta nên đề phòng (ví dụ, có một số loại chi phí bất thường để chuyển từ / sang tính toán shader khi chạy) không?

Có lẽ có những lợi ích hoặc hạn chế khác để xem xét khi lựa chọn giữa hai?


Nếu thẻ hiệu suất thực sự có liên quan, thì hãy xem xét video này từ bài viết "Mô phỏng vải" của Game Engine Gems từ Marco Fratarcangeli: youtube.com/watch?v=anNClcux4JQ . Bạn có thể đọc các bình luận và tìm ra một điều khó xử: việc triển khai dựa trên GLSL / shader nhanh hơn so với sử dụng CUDA hoặc OpenCL (sau này vì hỗ trợ trình điều khiển kém vào thời điểm đó, vào năm 2010). Có một số khác biệt cấp thấp nhất định .. tạo nên sự khác biệt.
teodron

@teodron Tôi không có sẵn GPU Gems và tôi không thể tìm thấy mã nguồn. Có phải tác giả đã thực sự sử dụng các shader đỉnh + pixel của GLSL hay anh ta đã sử dụng các shader tính toán GLSL?
TravisG

Đúng! Trước CUDA, đó là cách cộng đồng triển khai các tính năng GPGPU. Đây là một liên kết đến OpenCloth để xem người ta có thể đạt được điều đó như thế nào khi sử dụng GLSL HOẶC Cuda thuần túy: code.google.com/p/opencloth/source/browse/trunk/
Lỗi

Câu trả lời:


7

Không có câu trả lời đúng nếu bạn sẽ được hưởng lợi trực tiếp từ việc đánh giá shadrs / GPGPU tính toán, điều này phụ thuộc nhiều vào loại thuật toán bạn đang triển khai, tính toán shader và CUDA / OpenCL là một cách tiếp cận tổng quát hơn để khắc phục một số hạn chế của ngôn ngữ shading cũ hack. những lợi ích quan trọng nhất bạn sẽ nhận được:

  • Truy cập thông tin không gian. trong bản hack GLSL cũ (tốt, đó là một bản hack!) chỉ cung cấp ít thông tin về các đoạn lân cận vì nó sử dụng tọa độ kết cấu. Trong tính toán shader / CUDA / OpenCL truy cập thông tin không gian linh hoạt hơn nhiều, giờ đây bạn có thể thực hiện các thuật toán như cân bằng biểu đồ trên GPU với truy cập kết cấu / bộ đệm không theo thứ tự.
  • Cung cấp cho bạn đồng bộ hóa chủ đề và nguyên tử .
  • Tính toán không gian: bản hack GLSL cũ sẽ kết nối không gian tính toán đỉnh / đoạn với shader của bạn. Mảnh shader sẽ chạy với số lượng mảnh, shader đỉnh sẽ chạy với số lượng đỉnh. Trong tính toán shader bạn xác định không gian của riêng bạn.
  • Khả năng mở rộng : trình tạo bóng tính toán / CUDA / OpenCL của bạn có thể mở rộng theo số lượng GPU SM (Bộ đa xử lý phát trực tuyến) không giống như trình tạo bóng GLSL cũ của bạn nên được thực thi trên cùng SM. (Dựa trên những nhận xét của Nathan Reed, anh ta nói rằng điều đó không đúng, và các shader nên mở rộng tốt như các shader tính toán. Tôi vẫn không chắc chắn mặc dù tôi cần kiểm tra tài liệu).
  • Chuyển đổi ngữ cảnh : Cần có một số chuyển đổi ngữ cảnh, nhưng tôi sẽ nói rằng phụ thuộc vào ứng dụng để đặt cược tốt nhất của bạn là hồ sơ ứng dụng của bạn.

Tốt trong quan điểm của tôi , nếu bạn muốn đi con đường shaders tính toán, mặc dù các thuật toán nhất định có thể phù hợp hơn, có một số cân nhắc bạn cần phải đưa vào tài khoản:

  1. Phần cứng và khả năng tương thích ngược . Máy tính bóng chỉ có sẵn trong phần cứng mới hơn và nếu bạn đang dùng một sản phẩm thương mại (ví dụ: trò chơi), bạn cần phải hy vọng rằng nhiều người dùng có thể không chạy được sản phẩm của bạn.
  2. Bạn thường cần thêm kiến ​​thức về kiến ​​trúc GPU / CPU , lập trình song song và đa luồng (ví dụ: chia sẻ bộ nhớ, đồng bộ hóa bộ nhớ, đồng bộ hóa luồng, nguyên tử và nó ảnh hưởng đến hiệu suất) mà bạn thường không cần sử dụng trình tạo bóng thông thường .
  3. Tài nguyên học tập , từ kinh nghiệm có rất ít tài nguyên học tập cho tính toán shadrs, OpenCL và CUDA (cũng cung cấp khả năng tương tác OpenGL) so với lộ trình shader thông thường.
  4. Các công cụ gỡ lỗi , với việc thiếu gỡ lỗi thích hợp, việc phát triển công cụ có thể trở nên khó khăn hơn nhiều so với hầu hết các trình tạo bóng, ít nhất các trình tạo bóng có thể được gỡ lỗi một cách trực quan.
  5. Tôi hy vọng các shader tính toán sẽ cho hiệu năng tốt hơn so với thuật toán tương tự trong các shader khác; nếu chúng được thực hiện đúng khi xem xét mọi thứ từ điểm 2, vì chúng được thiết kế để tránh các bước bổ sung cho kết xuất đồ họa. Nhưng tôi không có bằng chứng cụ thể để hỗ trợ cho yêu cầu của mình.
  6. Bạn cũng nên xem xét CUUDA / OpenCL cho GPGPU nếu bạn đang đi theo lộ trình đó.

Không bao giờ tôi ít chắc chắn rằng nó tuyệt vời cho tương lai, và sẽ là trải nghiệm học tập tuyệt vời. Chúc may mắn!


Tôi nghĩ rằng OP có thể hỏi điều này: tại sao giải quyết vấn đề bằng cách sử dụng trình tạo bóng GLSL thuần túy so với mã hóa nó trong CUDA? Có một bài viết Đá quý lập trình trò chơi liên quan đến mô phỏng vải nơi tác giả làm điều đó. Và GLSL hacky cách cũ tốt hơn so với cách CUDA về hiệu suất. Bạn có thể nên chỉ ra lý do tại sao nếu bạn có bất kỳ ý tưởng tại sao.
teodron

2
Tôi không nghĩ rằng điểm khả năng mở rộng của bạn là chính xác - các shader đỉnh và mảnh cũng có khả năng mở rộng trên toàn bộ GPU giống như các shader tính toán. Trên thực tế, các shader tính toán có thể khó mở rộng hơn, vì kích thước nhóm luồng và việc sử dụng bộ nhớ dùng chung có thể đặt ra các giới hạn bổ sung về số lượng luồng shader có thể chạy cùng một lúc.
Nathan Reed

2
Ngoài ra, nếu bạn đang tạo một kết cấu (ví dụ: tạo ra nhiễu hoặc thực hiện một số thuật toán thủ tục khác), theo kinh nghiệm của tôi, một shader mảnh sẽ nhanh hơn một shader tính toán nếu bạn chỉ đánh giá một công thức ở mỗi pixel. Tôi đoán điều này là do thứ tự phân đoạn khớp với thứ tự pixel được lát gạch / bị xáo trộn bên trong, do đó có được vị trí bộ nhớ tốt hơn so với trình đổ bóng tính toán mà không biết về thứ tự này. Tính toán shader chỉ nhanh hơn nếu bạn có thể sử dụng các tính năng đặc biệt của chúng, ví dụ như bộ nhớ dùng chung, để tăng tốc mọi thứ lên rất nhiều so với shader mảnh.
Nathan Reed

2
OK, bình luận cuối cùng. :) Tôi nghĩ rằng hầu hết các GPU hiện tại có một số loại chuyển đổi ngữ cảnh hoặc chuyển đổi chế độ khi đi từ đồ họa để tính toán và ngược lại. Vì vậy, nếu bạn chạy một số shader đồ họa, sau đó gửi một shader tính toán, sau đó chạy thêm một số shader đồ họa, v.v., bạn sẽ phải chịu một số cú đánh hiệu năng khi chuyển đổi qua lại. Đó là thứ bạn phải lập hồ sơ, nhưng nó có thể là một lý do khác để gắn bó với các shader đồ họa trong một trường hợp cụ thể.
Nathan Reed

@NathanReed cảm ơn vì những bình luận tôi sẽ cập nhật câu trả lời của mình.
Concept3d
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.