Có bất kỳ lợi ích nào cho việc sử dụng CPU thay vì GPU không?

Tôi đã nghiên cứu bộ xử lý và card đồ họa và tôi phát hiện ra rằng GPU nhanh hơn CPU rất nhiều. Tôi đã đọc trong một bài viết này , GPU Nvidia 2 tuổi vượt trội hơn bộ xử lý Intel Core I7 tốc độ 3,2 GHz gấp 14 lần trong một số trường hợp nhất định. Nếu GPU nhanh như vậy, tại sao các nhà phát triển không sử dụng chúng cho mọi chức năng trong trò chơi? GPU có thể làm bất cứ điều gì khác ngoài đồ họa không?

"Tôi đã đọc được rằng những chiếc xe F1 nhanh hơn những chiếc chúng ta lái trên đường phố ... tại sao mọi người không sử dụng xe F1?" Chà ... Câu trả lời cho câu hỏi này rất đơn giản: những chiếc xe F1 không thể phá vỡ hoặc quay nhanh như hầu hết những chiếc xe khác (chiếc xe chậm nhất có thể đánh bại một chiếc F1 trong trường hợp đó). Trường hợp của GPU rất giống nhau, chúng rất giỏi trong việc xử lý theo đường thẳng, nhưng chúng không tốt lắm khi chọn các đường xử lý khác nhau.

Một chương trình được thực thi trong te GPU có ý nghĩa khi nó phải được thực thi song song nhiều lần, ví dụ như khi bạn phải trộn tất cả các pixel từ Texture A với các pixel từ Texture B và đặt tất cả chúng vào Texture C. Nhiệm vụ này, khi được thực thi trong CPU, sẽ được xử lý như thế này:

for( int i =0; i< nPixelCount; i++ )
     TexC[i] = TexA[i] + TexB[i];

Nhưng điều này chậm khi bạn phải xử lý nhiều pixel, vì vậy GPU thay vì sử dụng mã ở trên, nó chỉ sử dụng cái tiếp theo:

     TexC[i] = TexA[i] + TexB[i];

và sau đó nó điền vào tất cả các lõi với chương trình này (về cơ bản là sao chép chương trình vào lõi), gán một giá trị icho mỗi lõi . Sau đó là nơi xuất hiện phép thuật từ GPU và làm cho tất cả các lõi thực thi chương trình cùng một lúc , thực hiện nhiều thao tác nhanh hơn nhiều so với chương trình CPU tuyến tính có thể làm.

Cách làm việc này là ổn khi bạn phải xử lý theo cùng một cách rất nhiều đầu vào nhỏ, nhưng thực sự tồi tệ khi bạn phải tạo một chương trình có thể có phân nhánh có điều kiện. Vì vậy, bây giờ hãy xem CPU làm gì khi kiểm tra một số điều kiện:

• 1: Thực thi chương trình cho đến khi hoạt động logic đầu tiên
• 2: Đánh giá
• 3: Tiếp tục thực hiện từ kết quả địa chỉ bộ nhớ của phép so sánh (như với lệnh asm JNZ)

Điều này rất nhanh đối với CPU khi thiết lập một chỉ mục, nhưng để GPU làm điều tương tự, nó phức tạp hơn rất nhiều. Bởi vì sức mạnh từ GPU đến từ việc thực hiện cùng một lệnh cùng một lúc (chúng là lõi SIMD), chúng phải được đồng bộ hóa để có thể tận dụng kiến ​​trúc chip. Phải chuẩn bị GPU để đối phó với các nhánh ngụ ý ít nhiều:

• 1: Tạo một phiên bản của chương trình chỉ theo nhánh A, điền mã này vào tất cả các lõi.
• 2: Thực thi chương trình cho đến khi hoạt động logic đầu tiên
• 3: Đánh giá tất cả các yếu tố
• 4: Tiếp tục xử lý tất cả các phần tử theo nhánh A, liệt kê tất cả các quy trình đã chọn đường dẫn B (không có chương trình nào trong lõi!). Bây giờ tất cả các lõi đã chọn đường dẫn B, sẽ là IDLE !! - trường hợp xấu nhất là một lõi thực thi và mọi lõi khác chỉ chờ.
• 5: Khi tất cả Như đã xử lý xong, hãy kích hoạt phiên bản nhánh B của chương trình (bằng cách sao chép nó từ bộ đệm vào bộ nhớ lõi nhỏ).
• 6: Thi hành nhánh B.
• 7: Nếu được yêu cầu, pha trộn / hợp nhất cả hai kết quả.

Phương pháp này có thể thay đổi dựa trên rất nhiều thứ (ví dụ: một số rất nhỏcác nhánh có thể chạy mà không cần sự phân biệt này) nhưng bây giờ bạn đã có thể thấy tại sao việc phân nhánh sẽ là một vấn đề. Bộ nhớ GPU rất nhỏ, bạn không thể thực hiện một chương trình từ VRAM theo cách tuyến tính, nó phải sao chép các khối lệnh nhỏ vào lõi để thực thi và nếu bạn có đủ các nhánh thì GPU của bạn sẽ bị đình trệ hơn là thực thi bất kỳ mã nào, không có ý nghĩa gì khi xuất hiện khi thực hiện một chương trình chỉ theo một nhánh, như hầu hết các chương trình làm - ngay cả khi chạy trong nhiều luồng. So với ví dụ F1, điều này sẽ giống như phải mở dù phanh ở mọi góc, sau đó ra khỏi xe để đóng gói lại trong xe cho đến góc tiếp theo bạn muốn quay lại hoặc tìm một semaphore màu đỏ (góc tiếp theo nhiều khả năng).

Tất nhiên, có một vấn đề là các kiến ​​trúc khác rất giỏi trong nhiệm vụ vận hành logic, rẻ hơn và đáng tin cậy hơn, nổi bật hơn, được biết đến nhiều hơn, tiết kiệm điện hơn, v.v. sử dụng các hướng dẫn asm khác nhau giữa chúng thậm chí là từ cùng một nhà sản xuất và hiện tại hầu hết các ứng dụng máy tính không yêu cầu kiểu kiến ​​trúc song song này và ngay cả khi chúng cần chúng, chúng có thể sử dụng thông qua apis tiêu chuẩn như OpenCL như được đề cập bởi eBusiness, hoặc thông qua apis đồ họa. Có lẽ trong một vài thập kỷ, chúng ta sẽ có GPU có thể thay thế CPU nhưng tôi không nghĩ nó sẽ xảy ra bất cứ lúc nào.

Tôi giới thiệu tài liệu từ AMD APP giải thích rất nhiều về kiến ​​trúc GPU của họ và tôi cũng đã thấy về những cái NVIDIA trong hướng dẫn sử dụng CUDA, giúp tôi hiểu rất nhiều về điều này. Tôi vẫn không hiểu một số điều và tôi có thể bị nhầm lẫn, có lẽ ai đó biết nhiều hơn có thể xác nhận hoặc từ chối tuyên bố của tôi, điều này sẽ rất tốt cho tất cả chúng ta.

GPU là một nhiệm vụ song song rất tốt. Thật tuyệt ... nếu bạn đang chạy một tác vụ song song.

Trò chơi là về loại ứng dụng ít song song nhất . Hãy suy nghĩ về vòng lặp trò chơi chính. AI (giả sử người chơi được xử lý như một trường hợp đặc biệt của AI) cần phản ứng với các va chạm được phát hiện bởi vật lý. Do đó, nó phải chạy sau đó. Hoặc ít nhất, vật lý cần phải gọi các thói quen AI trong ranh giới của hệ thống vật lý (thường không phải là một ý tưởng tốt vì nhiều lý do). Đồ họa không thể chạy cho đến khi vật lý chạy, bởi vì vật lý là thứ cập nhật vị trí của các vật thể. Tất nhiên, AI cũng cần phải chạy trước khi kết xuất, vì AI có thể sinh ra các đối tượng mới. Âm thanh cần phải chạy sau khi điều khiển AI và người chơi

Nói chung, các trò chơi có thể tự xâu chuỗi theo rất ít cách. Đồ họa có thể được quay ra trong một chủ đề; vòng lặp trò chơi có thể đẩy một loạt dữ liệu vào luồng đồ họa và nói: kết xuất cái này. Nó có thể thực hiện một số phép nội suy cơ bản, để vòng lặp trò chơi chính không phải đồng bộ với đồ họa. Âm thanh là một chủ đề khác; vòng lặp trò chơi nói "chơi cái này" và nó được chơi.

Sau đó, tất cả bắt đầu đau đớn. Nếu bạn có các thuật toán đường dẫn phức tạp (chẳng hạn như đối với RTS), bạn có thể xâu chuỗi chúng. Có thể mất một vài khung để các thuật toán hoàn thành, nhưng ít nhất chúng sẽ đồng thời. Ngoài ra, nó khá khó.

Vì vậy, bạn đang xem xét 4 chủ đề: trò chơi, đồ họa, âm thanh và có thể xử lý AI dài hạn. Đó không phải là nhiều. Và điều đó gần như không đủ cho GPU, có thể có hàng trăm luồng trong cùng một lúc. Đó là những gì mang lại cho GPU hiệu năng của chúng: có thể sử dụng tất cả các luồng đó cùng một lúc. Và trò chơi đơn giản là không thể làm điều đó.

Bây giờ, có lẽ bạn có thể có thể "mở rộng" cho một số hoạt động. AI, ví dụ, thường độc lập với nhau. Vì vậy, bạn có thể xử lý vài chục AI cùng một lúc. Phải cho đến khi bạn thực sự cần phải làm cho họ phụ thuộc vào nhau. Sau đó, bạn đang gặp rắc rối. Các đối tượng vật lý độc lập tương tự ... trừ khi có một ràng buộc giữa chúng và / hoặc chúng va chạm với một cái gì đó. Sau đó, họ trở nên rất phụ thuộc.

Thêm vào đó, có một thực tế là GPU đơn giản là không có quyền truy cập vào đầu vào của người dùng, mà theo tôi hiểu là loại quan trọng đối với các trò chơi. Vì vậy, sẽ phải được cung cấp. Nó cũng không có quyền truy cập tệp trực tiếp hoặc bất kỳ phương pháp thực sự nào để nói chuyện với HĐH; vì vậy một lần nữa, sẽ phải có một số cách để cung cấp điều này. Oh, và tất cả những gì xử lý âm thanh? GPU không phát ra âm thanh. Vì vậy, những người phải quay trở lại CPU và sau đó ra chip âm thanh.

Ồ, và mã hóa cho GPU là khủng khiếp. Thật khó để hiểu đúng và điều gì là "đúng" đối với một kiến ​​trúc GPU có thể rất, rất sai đối với một kiến trúc khác. Và đó thậm chí không chỉ chuyển từ AMD sang NVIDIA; có thể chuyển từ GeForce 250 sang GeForce 450. Đó là một sự thay đổi trong kiến ​​trúc cơ bản. Và nó có thể dễ dàng làm cho mã của bạn không chạy tốt. C ++ và thậm chí C không được phép; thứ tốt nhất bạn nhận được là OpenCL, giống như C nhưng không có một số chi tiết. Thích đệ quy . Điều đó đúng: không có đệ quy trên GPU.

Gỡ lỗi? Ồ tôi hy vọng bạn không thích các tính năng sửa lỗi IDE của mình, vì những tính năng này chắc chắn sẽ không khả dụng. Ngay cả khi bạn đang sử dụng GDB, hãy hôn tạm biệt. Bạn sẽ phải dùng đến việc printfgỡ lỗi ... chờ đã, không có printfGPU. Vì vậy, bạn sẽ phải ghi vào các vị trí bộ nhớ và để chương trình sơ khai CPU của bạn đọc lại chúng.

Đúng vậy: thủ công gỡ lỗi. Chúc may mắn với điều đó.

Ngoài ra, những thư viện hữu ích mà bạn sử dụng trong C / C ++? Hoặc có lẽ bạn là một người .NET hơn, sử dụng XNA và vv. Hay bất cứ cái gì. Không thành vấn đề, vì bạn không thể sử dụng bất kỳ trong số chúng trên GPU. Bạn phải mã hóa mọi thứ từ đầu. Và nếu bạn đã có một cơ sở mã đã tồn tại, khó khăn: thời gian để viết lại tất cả các mã đó.

Vì vậy, vâng. Thật kinh khủng khi thực sự làm cho bất kỳ loại trò chơi phức tạp nào. Và nó thậm chí sẽ không hoạt động, bởi vì các trò chơi không đủ song song để giúp nó.

Tại sao không dễ trả lời - điều quan trọng cần lưu ý là GPU là bộ xử lý chuyên dụng không thực sự dành cho sử dụng chung như CPU ​​thông thường. Do tính chuyên môn hóa này, không có gì đáng ngạc nhiên khi GPU có thể vượt trội hơn CPU đối với những thứ được thiết kế riêng (và tối ưu hóa), nhưng điều đó không nhất thiết có nghĩa là nó có thể thay thế toàn bộ chức năng và hiệu suất của CPU tổng quát.

Tôi nghi ngờ rằng các nhà phát triển không làm điều này vì nhiều lý do, bao gồm:

• Họ muốn đồ họa có tốc độ nhanh nhất và chất lượng cao nhất có thể, và sử dụng tài nguyên GPU có giá trị có thể cản trở điều này.

• Mã dành riêng cho GPU có thể phải được viết và điều này có thể sẽ giới thiệu thêm độ phức tạp cho việc lập trình tổng thể của trò chơi (hoặc ứng dụng) trong tay.

• GPU thông thường không có quyền truy cập vào các tài nguyên như card mạng, bàn phím, chuột và cần điều khiển, vì vậy dù sao nó cũng không thể xử lý mọi khía cạnh của trò chơi.

Trả lời cho phần thứ hai của câu hỏi của bạn: Có, có những cách sử dụng khác. Ví dụ: các dự án như SETI @ Home (và có thể là các dự án BOINC khác) đang sử dụng GPU (chẳng hạn như các dự án của nVidia) để tính toán phức tạp tốc độ cao:

  Chạy SETI @ home trên GPU NVIDIA của bạn http: //setiathome.ber siêu.edu /
  cuda.php

( Tôi thích câu hỏi của bạn vì nó đặt ra một ý tưởng thú vị. )

CPU linh hoạt hơn, thường dễ lập trình hơn, chúng có thể chạy các luồng đơn nhanh hơn rất nhiều.

Mặc dù các GPU hiện đại có thể được lập trình để giải quyết khá nhiều nhiệm vụ, chúng chỉ đạt được lợi thế về tốc độ khi chúng có thể sử dụng kiến ​​trúc song song của chúng. Đây thường là trường hợp với các nhiệm vụ "đơn giản" lặp đi lặp lại. Rất nhiều mã chúng tôi viết đang phân nhánh quá khó lường để chạy hiệu quả trên GPU.

Trên hết, bạn có thể sẽ dành rất nhiều thời gian để tối ưu hóa mã cho các chip đồ họa khác nhau. Mặc dù OpenCL có sẵn để làm cho cùng một mã chạy trên nhiều chip đồ họa khác nhau, bạn sẽ đánh đổi một số lợi thế về tốc độ cho sự xa xỉ này.

Từ góc độ lập trình viên trò chơi, chúng tôi thường muốn trò chơi của chúng tôi chạy trên các máy tính có card đồ họa ít hơn. Một số chip tích hợp không có khả năng lập trình cần thiết, nhưng nếu chúng hoạt động chậm đến mức chúng sẽ không đánh bại bộ xử lý bằng một mức lợi nhuận rất lớn, ngay cả đối với loại công việc mà chúng phải giỏi. Và tất nhiên, nếu bạn đã chạm vào GPU cấp thấp cho một trò chơi, bạn sẽ cần sức mạnh xử lý rất cần thiết từ kết xuất đồ họa.

Quả thực triển vọng là rất lớn, nhưng khi bạn đang tạo ra một trò chơi thay vì bẻ khóa mật khẩu, các vấn đề thực tế trong hầu hết các trường hợp vượt trội hơn lợi ích.

GPU rất khó lập trình. Bạn nên tìm kiếm cách sắp xếp danh sách trên GPU . Nhiều luận án đã tìm kiếm để làm điều đó.

Sử dụng CPU với một luồng thì dễ, sử dụng đa luồng thì khó hơn, sử dụng nhiều máy tính có thư viện song song vì PVM hoặc MPI khó và sử dụng gpu là khó nhất.

Khác với những gì Randolf Richardson trả lời, có một số chức năng nhất định mà bộ xử lý GPU không thể tự xử lý. Ví dụ: một số lệnh quản lý bộ nhớ đồ họa được CPU xử lý do GPU không thể xử lý chúng.

Và có một lý do lớn khác, GPU được thiết kế để tính toán đa luồng. Điều này có nghĩa là các nhà sản xuất GPU có thể dễ dàng thêm lõi bất cứ khi nào họ muốn tăng sức mạnh tính toán. Nhưng có nhiều nhiệm vụ không thể chia thành các vấn đề nhỏ hơn như tính toán số thứ n trong chuỗi Fibonacci . Trong những tình huống này, CPU nhanh hơn nhiều vì nó được tối ưu hóa hơn cho các tác vụ đơn luồng.

Có rất nhiều câu trả lời cho thấy GPU chỉ nhanh hơn vì chúng xử lý các tác vụ song song. Đây là nói quá vấn đề một chút. GPU có thể hiệu quả hơn vì những lý do khác, chẳng hạn như có thể truy cập bộ nhớ hạn chế hơn, không phải hỗ trợ nhiều loại dữ liệu, có thể có bộ hướng dẫn hiệu quả hơn, v.v. GPU sớm vẫn chỉ có thể vẽ 1 pixel tại một thời gian, nhưng thực tế là họ có thể làm 1 chu kỳ quan trọng.

Sự khác biệt thực sự là bởi vì chúng là 2 loại máy khác nhau được tùy chỉnh để hoạt động tốt trên các loại nhiệm vụ khác nhau có vẻ giống nhau nhưng thực sự khá khác nhau. Nó giống như so sánh một chiếc máy bay với một chiếc xe hơi. Máy bay có tốc độ tối đa cao hơn nhiều nhưng có nhiều hạn chế hơn về cách sử dụng. Vào những dịp mà bạn có thể thực hiện cùng một hành trình với một trong hai loại, máy bay có vẻ vượt trội.

Các nhà phát triển làm sử dụng GPU cho tất cả các chức năng họ đang tốt tại. Họ sử dụng CPU cho tất cả các chức năng mà họ giỏi. Điều gì khiến bạn nghĩ rằng họ không?

GPU rất giỏi trong các nhiệm vụ có thể bị liệt ngang hàng loạt và yêu cầu số lượng tính toán lớn với yêu cầu bộ nhớ thấp hoặc tương quan thời gian cao chỉ với một lượng nhỏ ra quyết định. Điều này bao gồm kết xuất hình ảnh, mô phỏng vật lý (hạt, va chạm, vải, nước, phản chiếu) và như vậy. Vì vậy, đây chính xác là những gì các trò chơi hiện đại sử dụng GPU cho.

CPU rất tốt trong các nhiệm vụ không song song tốt và đòi hỏi số lượng lớn quyết định. Họ có thể chịu đựng được yêu cầu bộ nhớ cao ngay cả khi chỉ có tương quan thời gian vừa phải. Điều này bao gồm trí tuệ nhân tạo, giao diện người dùng, I / O đĩa và mạng, v.v. Vì vậy, đây chính xác là những gì các trò chơi hiện đại sử dụng CPU cho.

Đọc lại là một lý do khác mà tôi có thể nghĩ đến để thỉnh thoảng thích CPU. Không phải về mặt băng thông (vì GPU-> Băng thông CPU không phải là vấn đề quá lớn đối với phần cứng hiện đại) mà là về mặt đình trệ đường ống. Nếu bạn cần lấy lại kết quả từ một tính toán và làm điều gì đó thú vị hoặc hữu ích với chúng, sử dụng GPU không phải là một lựa chọn khôn ngoan (trong trường hợp chung - sẽ có những trường hợp đặc biệt có thể vẫn phù hợp) vì việc đọc lại sẽ luôn yêu cầu GPU để dừng bất cứ điều gì nó đang làm, xóa tất cả các lệnh đang chờ xử lý và chờ cho quá trình đọc lại hoàn tất. Điều này có thể giết chết hiệu suất đến mức nó không chỉ xóa sạch lợi ích của việc sử dụng GPU, mà thực sự có thể chậm hơn đáng kể.

Đây là một chủ đề cũ, nhưng bài báo được xuất bản gần đây này có thể trả lời câu hỏi này. Bài viết này, được xuất bản trong Khảo sát điện toán ACM 2015 cho thấy mỗi CPU và GPU đều có những ưu điểm riêng và do đó, bài viết này tạo ra một trường hợp để chuyển từ mô hình "tranh luận giữa CPU và GPU" sang mô hình "tính toán hợp tác CPU-GPU".

Khảo sát các kỹ thuật tính toán không đồng nhất CPU-GPU