Biến đổi hình học trên CPU so với GPU


9

Tôi đã nhận thấy rằng nhiều chương trình 3d thường thực hiện các phép tính vectơ / ma trận cũng như các phép biến đổi hình học trên CPU. Có ai tìm thấy một lợi thế trong việc di chuyển các tính toán này thành các shader đỉnh trên GPU không?

Câu trả lời:


3

Nói chung: Biến đổi lưới được thực hiện trên GPU. Bạn gửi ma trận chuyển đổi tới GPU và trình đổ bóng áp dụng nó cho tất cả các đỉnh của lưới.

Sử dụng GPU để tự tính toán Ma trận là một vấn đề khác & thực sự chậm hơn trên GPU vì có rất nhiều giá trị được lưu trữ thay đổi từ khung này sang khung khác cần thiết để giúp xác định ma trận biến đổi cuối cùng. Gửi dữ liệu này đến & từ CPU - GPU chậm. Ngoài ra, trên CPU, các phép tính được thực hiện một lần, trong khi trên GPU, chúng sẽ được thực hiện cho từng đỉnh.


Viết phần "thực sự chậm hơn trên GPU"; đây là một tuyên bố rất rộng Nếu bạn đang nói về việc xây dựng ma trận cho từng đỉnh trên GPU thì hiệu suất của bạn sẽ phụ thuộc vào các tắc nghẽn của bạn. Bạn sẽ chỉ nhận được hiệu suất chậm hơn nếu bạn bị ALU / đăng ký bị ràng buộc trên GPU, điều này không nhất thiết phải như vậy. Làm chính xác điều tương tự trên CPU cũng sẽ chậm hơn trong các tình huống tắc nghẽn này. Một ví dụ nơi này được phổ biến thực hiện trên GPU: ma trận không gian đỉnh tangent vertex shader xây dựng một cách nhanh chóng để cứu lấy đỉnh băng thông. Một lần nữa, phụ thuộc vào nút cổ chai của bạn, vì vậy YMMV.
32 phút

Tôi không thể downvote, nhưng câu trả lời này nên được bỏ qua. Thật sai lầm khi nói "thực sự chậm hơn trên GPU".
Adam

3

Nhiều biến đổi hình học có thể được thực hiện trên các bộ xử lý không phải GPU, tuy nhiên người ta phải xem xét nền tảng đích. Số dặm của bạn sẽ thay đổi dựa trên nền tảng bạn đang nhắm mục tiêu và các nút thắt của nền tảng đó.

Một xem xét là băng thông bus giữa thiết bị tạo hình học và thiết bị hiển thị hình học.

Trong một hệ thống PC hiện đại điển hình, CPU nằm ở một bên của bus PCIe (http://en.wikipedia.org/wiki/PCI_Express) và GPU ở phía bên kia. Cách duy nhất bạn có thể chuyển dữ liệu được tạo trên mỗi khung hình từ CPU sang GPU (và ngược lại) là thông qua xe buýt này. Điều này có nghĩa, bạn có thể bị giới hạn bởi tốc độ chuyển của xe buýt này. Nếu nền tảng mục tiêu của bạn có PCIe 2.x với 16 làn, bạn có băng thông 8GB / s. Trong thực tế, chuyển tiền qua PCIe không hiệu quả 100%, vì một số băng thông được sử dụng cho giao thức trong quá trình chuyển của bạn. Tùy thuộc vào kích thước chuyển khoản của bạn, bạn có thể mất 5-10% băng thông chỉ trên chi phí cho mỗi gói.

ví dụ. Với một nền tảng PC đang chạy PCIe 2.x với 16 làn, bạn có thể tạo bao nhiêu dữ liệu trên mỗi khung hình để cung cấp cho GPU? Giả sử bạn muốn chạy ở tốc độ 60fps, điều này chuyển thành 8GB / 60 = 136MB mỗi khung hình cho PCIe 2.x. Nhân với một số yếu tố (được đánh giá cao) 90% để tính toán chi phí truyền thông trình điều khiển và giao thức truyền tải PCIe, bạn có thể tạo khoảng 120Mb dữ liệu trên mỗi khung hình mà không bị giới hạn bởi băng thông PCIe 2.x.

Một câu hỏi khác mà bạn phải trả lời: việc tạo ra 120Mb dữ liệu này có thể dễ dàng đạt được trong 1/60 giây trên CPU mục tiêu của bạn không? Hãy nhớ rằng bạn phải thực hiện một số tác vụ trò chơi khác trên CPU của mình, bạn có thể gặp phải tình trạng thiếu thời gian để tạo dữ liệu được chuyển đổi. Xét về thông lượng ALU thuần túy, điều này có thể giới hạn bạn trên CPU. Về mặt CPU đối với các bus sysmem, bạn cũng có thể bị giới hạn bởi băng thông (có thể thay đổi, nhưng khoảng ~ 8,5 GB / giây trên các CPU gần đây).

Được rồi, vậy yếu tố nào làm cho nó khả thi hơn trên GPU sau đó? Một yếu tố là băng thông bộ nhớ GPU, đó là băng thông giữa GPU và bộ nhớ video cục bộ. Trên các GPU tầm trung hiện đại, băng thông bộ nhớ video này có thể lên tới 200GB / giây (vâng, đó là 25 lần băng thông PCIe 2.x). Một yếu tố khác là GPU song song ồ ạt, có hàng trăm ALU và có thể che giấu độ trễ truy cập bộ nhớ bằng cách chạy hàng ngàn luồng cùng một lúc.

Tất cả các yếu tố này có thể góp phần vào chiến thắng rõ ràng khi đẩy nhiều công việc hơn vào GPU, nhưng một lần nữa YMMV tùy thuộc vào nền tảng mục tiêu của bạn.


1

Bạn có ý nghĩa gì bởi "biến đổi lưới"? Biến đổi hình học bằng một số ma trận? Hầu hết các trò chơi ngày nay sẽ cho phép GPU xử lý các biến đổi đơn giản, lột da, v.v. Và hầu hết trong số chúng sẽ sử dụng các shader đỉnh để làm điều đó. Trên một số nền tảng, bạn không có trình tạo bóng hoặc có những lợi thế khác khi thực hiện những điều này trên CPU. Ví dụ, trên PS3, bạn có thể giảm tải RSX bằng cách để SPU xử lý giao diện và chuyển đổi. Nếu bạn đang thực hiện chiếu sáng nhiều lượt thì việc tạo lớp nền cho CPU có thể thuận lợi, vì bạn chỉ phải thực hiện một lần và gửi kết quả sẽ được rút ra cho mỗi lần kết xuất. Vì vậy, có những trường hợp ngoại lệ, nhưng nói chung hầu hết các trò chơi đang làm những điều này trên GPU và trong shader.

Hay bạn có ý gì đó kỳ lạ hơn, như sử dụng GPU cho toán học vectơ nói chung? Ngày nay chúng ta có GPU mục đích chung có thể chạy mã C khá chung thông qua các hệ thống như CUDA. Có thể tận dụng lợi thế này cho toán học vectơ nặng, và tôi biết có những chương trình ngoài kia thực hiện điều này. Tôi không có bất kỳ kinh nghiệm với cá nhân mặc dù.


đã thay đổi "biến đổi lưới" thành "biến đổi hình học" để giúp làm rõ câu hỏi. Tôi cũng đang chờ đợi opencl es, có thể sẽ sớm ra mắt vào năm tới.
zmdat

0

Có những tình huống khi mọi thứ được hiển thị trên GPU có thể có ý nghĩa, nhưng bạn không thể đặt các hằng số bên trong một shader và thực sự không có nơi nào khác để thiết lập chúng ngoại trừ phía CPU trước lệnh gọi rút thăm.

Ngay cả khi bạn có thể tính toán các hằng số của mình, như ma trận biến đổi xương, trên GPU với chương trình khởi tạo tùy chỉnh, có lẽ bạn sẽ không muốn. GPU thực sự tốt khi thực hiện song song, nhưng có tốc độ xung nhịp chậm hơn nhiều.

Chuyển đổi một hệ thống phân cấp không phải là song song, bởi vì các nút con phụ thuộc vào cha mẹ, nhưng chuyển đổi tất cả các đỉnh trong một lưới là bởi vì các đỉnh là tính toán độc lập với nhau.

Nguyên tắc chung là:

  • Xử lý nối tiếp: CPU
  • Xử lý song song: GPU
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.