Tại sao đồ họa vector tăng tốc phần cứng không được đưa ra?

Tôi đang làm việc trên một ứng dụng liên quan đến thao tác thời gian thực của các đường dẫn vectơ ở tốc độ 60fps và tôi rất ngạc nhiên bởi có rất ít thông tin về chủ đề này. Lúc đầu, tôi đã cố gắng thực hiện ý tưởng của mình bằng CoreGraphics, nhưng nó không thực hiện đầy đủ cho mục đích của tôi . Sau đó tôi phát hiện ra rằng có một tiêu chuẩn Khronos cho đồ họa vector tăng tốc phần cứng được gọi là OpenVG , và may mắn thay, một linh hồn tốt bụng đã viết một triển khai bán OpenGL ES có tên là MonkVG .

Nhưng mặc dù thực tế rằng OpenVG là một API rất hữu dụng trong thực tế, nó dường như ít nhiều bị Khronos bỏ rơi. Theo Wikipedia, kể từ năm 2011, nhóm làm việc "quyết định ... không tổ chức bất kỳ cuộc họp thường kỳ nào [sic] để chuẩn hóa hơn nữa". Các tài liệu, tốt nhất tôi có thể tìm thấy, chỉ bao gồm một thẻ tham khảo duy nhất. Và hơn thế nữa, hầu như không có ví dụ nào về OpenVG ở bất cứ đâu trên internet. Tôi có thể tìm thấy hàng trăm hướng dẫn về OpenGL trong chớp mắt, nhưng OpenVG dường như bị thiếu một cách rõ rệt.

Bạn nghĩ rằng các vectơ tăng tốc phần cứng sẽ quan trọng hơn trong thế giới giải quyết tăng nhanh ngày nay và dường như nhiều công ty đang thực hiện những cách riêng của họ để làm điều này. Ví dụ: Qt và Flash có các sơ đồ cho các vectơ tăng tốc phần cứng và nhiều công cụ của Adobe có khả năng tăng tốc phần cứng như một tùy chọn. Nhưng có vẻ như bánh xe đang được phát minh lại khi một tiêu chuẩn đã tồn tại!

Có điều gì tôi thiếu về OpenVG khiến nó không phù hợp để sử dụng trong thế giới thực? Hay đó chỉ là tiêu chuẩn không bắt kịp kịp thời và bây giờ nó đã bị che khuất? Bạn có nghĩ rằng sẽ có chỗ cho một API được tiêu chuẩn hóa cho đồ họa vector được tăng tốc phần cứng trong tương lai không, hoặc sẽ dễ dàng hơn khi sử dụng các kỹ thuật dựa trên raster truyền thống? Hay là các vectơ chỉ đơn giản là trên đường ra, trước khi chúng được đưa vào?

cập nhật: Xem dưới cùng của trả lời

Câu trả lời này đến hơi muộn, nhưng tôi hy vọng sẽ chiếu sáng cho những người khác (đặc biệt là bây giờ ủy ban tiêu chuẩn C ++ muốn kết hợp Cairo vào std):

Lý do không ai thực sự quan tâm đến "đồ họa vector tăng tốc" là do cách thức hoạt động của GPU. GPU hoạt động bằng cách sử dụng song song lớn và khả năng SIMD để tô màu từng pixel. AMD thường hoạt động trong các khối 64x64 8x8 pixel trong khi thẻ NVIDIA thường hoạt động ở 32x32 4x4 pixel [Xem cập nhật ở phía dưới]

Ngay cả khi chúng hiển thị một hình tam giác 3D, GPU vẫn hoạt động trên toàn bộ hình tứ giác mà hình tam giác này bao phủ. Vì vậy, nếu một hình tam giác không bao gồm tất cả các pixel 8 x 8 trong khối (hoặc 4 x 4 trong trường hợp của nvidia), GPU sẽ tính toán màu của các pixel không được che và sau đó loại bỏ kết quả. Nói cách khác, sức mạnh xử lý cho các pixel không được phát hiện bị lãng phí. Mặc dù điều này có vẻ lãng phí, nhưng nó hoạt động cực kỳ tốt để hiển thị các hình tam giác 3D lớn khi được ghép nối với số lượng lớn lõi GPU (thông tin chi tiết hơn ở đây: Tối ưu hóa trình tạo điểm ảnh cơ bản ).

Vì vậy, khi chúng ta nhìn lại quá trình raster dựa trên vector, bạn sẽ nhận thấy rằng khi vẽ các đường kẻ, ngay cả khi chúng dày, vẫn có một khoảng trống lớn. Rất nhiều năng lượng xử lý bị lãng phí, và quan trọng hơn là băng thông (là nguyên nhân chính gây ra tiêu thụ năng lượng và thường là nút cổ chai) Vì vậy, trừ khi bạn vẽ một đường ngang hoặc dọc với bội số dày 8, và nó hoàn toàn phù hợp với Ranh giới 8 pixel, rất nhiều sức mạnh xử lý và băng thông sẽ bị lãng phí.

Lượng "chất thải" có thể được giảm bằng cách tính toán vỏ để kết xuất (giống như NV_path_Vndering), nhưng GPU vẫn bị giới hạn ở các khối 8x8 / 4x4 (có lẽ tỷ lệ điểm chuẩn GPU của NVIDIA tốt hơn với độ phân giải cao hơn, tỷ lệ pixel_packed / pixel_wazed thấp hơn nhiều).

Đây là lý do tại sao nhiều người thậm chí không quan tâm đến "gia tốc vector hw". GPU đơn giản là không phù hợp cho nhiệm vụ.

NV_path_Vndering là ngoại lệ nhiều hơn so với tiêu chuẩn và họ đã giới thiệu thủ thuật mới trong việc sử dụng bộ đệm stpson; hỗ trợ nén và có thể giảm đáng kể việc sử dụng băng thông.

Tuy nhiên, tôi vẫn hoài nghi của NV_path_rendering, và với một chút googling cho thấy Qt khi sử dụng OpenGL (còn gọi là cách được đề nghị) là nhanh hơn đáng kể so với NV_path_rendering NVIDIA: NV Đường dẫn render Nói cách khác, các slide của NVIDIA đã "vô tình" so sánh phiên bản của XRender của Qt. Ôi

Thay vì lập luận rằng "mọi thứ vẽ vector với tăng tốc hw đều nhanh hơn", các nhà phát triển Qt thừa nhận trung thực hơn việc vẽ vector tăng tốc CTNH không phải lúc nào cũng tốt hơn (xem cách hoạt động kết xuất của họ giải thích: Đồ họa và hiệu suất Qt - OpenGL )

Và chúng tôi đã không chạm vào một phần của đồ họa vector "chỉnh sửa trực tiếp", đòi hỏi phải tạo ra dải tam giác một cách nhanh chóng. Khi chỉnh sửa các Svss phức tạp, điều này thực sự có thể thêm chi phí nghiêm trọng.

Cho dù nó tốt hơn hay không, nó phụ thuộc nhiều vào các ứng dụng; như câu hỏi ban đầu của bạn "tại sao nó không được cất cánh", tôi hy vọng nó đã được trả lời: có nhiều nhược điểm và hạn chế cần phải tính đến, thường khiến nhiều người hoài nghi và thậm chí có thể khiến họ không thực hiện được .

cập nhật: Tôi đã chỉ ra rằng các con số hoàn toàn không có cơ sở, vì các GPU được đề cập không rasterize trong các khối 64x64 & 32x32 mà thay vào đó là 8x8 = 64 và 4x4 = 16. Điều này vô hiệu hóa rất nhiều kết luận của bài đăng. Tôi sẽ sớm cập nhật bài viết này sau với thông tin cập nhật hơn.

Tôi không nghĩ thực sự đúng là không ai thực sự quan tâm đến "đồ họa vector tăng tốc" như được viết trong câu trả lời này .

Nvidia dường như quan tâm một chút công bằng. Ngoài Kilgard, người là kỹ thuật viên hàng đầu về NV_path_Vndering (từ đó là NVpr để cứu ngón tay của tôi), chủ tịch của Khronos, Neil Trevett, cũng là phó chủ tịch tại Nvidia, đã quảng bá NVpr nhiều nhất có thể trong vài năm qua; thấy mình talk1 , talk2 hoặc talk3 . Và điều đó dường như đã được đền đáp một chút. Vào thời điểm viết bài này, NVpr hiện được sử dụng trong Skia của Google (lần lượt được sử dụng trong Google Chrome) và độc lập [của Skia] trong phiên bản beta của Adobe Illustrator CC (beta), theo slide của Kilgard tại GTC14 ; cũng có một số video về các cuộc đàm phán được đưa ra ở đó: Kilgard's và Adobe's. Một nhà phát triển Cairo (người làm việc cho Intel) cũng có vẻ quan tâm đến NVpr. Các nhà phát triển Mozilla / Firefox cũng đã thử nghiệm với NVpr và thực tế họ quan tâm đến đồ họa vector tăng tốc GPU nói chung như các chương trình trò chuyện FOSDEM14 này .

Microsoft cũng quan tâm một chút công bằng vì họ đã tạo Direct2D , được sử dụng khá rộng rãi [nếu bạn tin rằng nhà phát triển Mozilla từ cuộc nói chuyện đã nói ở trên].

Bây giờ để đi đến điểm của câu hỏi ban đầu: thực sự có một số lý do kỹ thuật tại sao việc sử dụng GPU để kết xuất đường dẫn không đơn giản. Nếu bạn muốn đọc về cách hiển thị đường dẫn khác với hình học đỉnh 3D tiêu chuẩn và điều gì làm cho việc tăng tốc GPU của kết xuất đường dẫn không tầm thường, thì Kilgard có một bài đăng giống như FAQ rất hay , không may bị chôn vùi ở đâu đó trong diễn đàn OpenGL.

Để biết thêm chi tiết về cách Direct2D, NVpr và những công việc như vậy, bạn có thể đọc bài báo Siggraph 2012 của Kilgard , tất nhiên tập trung vào NVpr, nhưng cũng thực hiện tốt công việc khảo sát các phương pháp tiếp cận trước đó. Đủ để nói rằng các bản hack nhanh không hoạt động quá tốt ... (như văn bản của câu hỏi PSE đã lưu ý.) Có những khác biệt đáng kể về hiệu suất giữa các cách tiếp cận này như được thảo luận trong bài báo đó và được thể hiện trong một số bản demo đầu tiên của Kilgard, ví dụ như trong video này . Tôi cũng cần lưu ý rằng tài liệu mở rộng NVpr chính thức chi tiết một số điều chỉnh hiệu suất trong những năm qua.

Chỉ vì NVpr không tuyệt vời trên Linux vào năm 2011 (trong lần triển khai đầu tiên được phát hành), vì bài đăng trên blog năm 2011 của Qt's Zack Rusin nói, điều đó không có nghĩa là việc tăng tốc vectơ / đường dẫn của GPU là vô vọng như câu trả lời của ông Goldberg dường như đã suy ra từ đó. Trên thực tế, Kilgard đã trả lời phần cuối của bài đăng trên blog đó với các trình điều khiển được cập nhật cho thấy sự cải thiện gấp 2 lần so với mã nhanh hơn của Qt và Rusin đã không nói gì sau đó.

Valve Corp cũng quan tâm đến kết xuất vector tăng tốc GPU, nhưng theo một cách hạn chế hơn, liên quan đến kết xuất phông chữ / glyph. Họ đã có một cách thực hiện nhanh chóng, làm mịn phông chữ lớn bằng cách sử dụng các trường khoảng cách đã ký tăng tốc GPU (SDF) được trình bày tại Siggraph 2007 , được sử dụng trong các trò chơi của họ như TF; có một video trình diễn kỹ thuật được đăng trên YouTube (nhưng tôi không chắc ai đã thực hiện điều đó).

Cách tiếp cận SDF đã thấy một số cải tiến của một trong những nhà phát triển Cairo & pango dưới dạng GLyphy ; tác giả của nó đã nói chuyện tại linux.conf.au 2014. Phiên bản quá dài không theo dõi là anh ta thực hiện xấp xỉ đường cong vòng cung của các đường cong Bezier để làm cho phép tính SDF trở nên dễ điều khiển hơn trong không gian vectơ (chứ không phải trong raster) (Valve đã làm sau). Nhưng ngay cả với xấp xỉ arc-spline, tính toán vẫn chậm; ông cho biết phiên bản đầu tiên của ông chạy ở tốc độ 3 khung hình / giây. Vì vậy, bây giờ anh ta thực hiện một số loại bỏ dựa trên lưới cho những thứ "quá xa", trông giống như dạng LOD (mức độ chi tiết) nhưng trong không gian SDF. Với sự tối ưu hóa này, các bản demo của anh ấy đã chạy ở tốc độ 60 khung hình / giây (và có lẽ nó bị giới hạn Vsync). Tuy nhiên, các shader của anh ta cực kỳ phức tạp và đẩy các giới hạn của phần cứng và trình điều khiển. Ông nói điều gì đó dọc theo dòng chữ: "đối với mọi kết hợp trình điều khiển / hệ điều hành, chúng tôi phải thay đổi mọi thứ". Ông cũng tìm thấy các lỗi đáng kể trong trình biên dịch shader, một số trong đó sau đó đã được sửa bởi các nhà phát triển tương ứng của họ. Nghe có vẻ giống như phát triển tựa game AAA ...

Trên một chiến thuật khác, có vẻ như Microsoft đã ủy thác / chỉ định một chút phần cứng GPU mới để cải thiện việc triển khai Direct2D của họ với, phần cứng được sử dụng bởi Windows 8, nếu có . Đây được gọi là rasterization độc lập mục tiêu ( TIR ), một cái tên hơi sai lệch so với những gì thực sự có vẻ như được thực hiện, được đánh vần trong ứng dụng bằng sáng chế của Microsoft . AMD tuyên bố rằng TIR cải thiện hiệu suất trong đồ họa vector 2D khoảng 500% . Và có một chút "cuộc chiến ngôn từ" giữa họ và Nvidia vì GPU của Kepler không có nó, trong khi GPU dựa trên GCN của AMD thì có. Nvidia đã xác nhậnrằng đây thực sự là một chút phần cứng mới, không chỉ đơn giản là thứ mà bản cập nhật trình điều khiển có thể cung cấp. Bài đăng trên blog của Sinofsky có thêm một vài chi tiết, bao gồm một số điểm chuẩn thực tế của TIR. Tôi chỉ trích dẫn các bit ý tưởng chung:

để cải thiện hiệu suất khi hiển thị hình học không đều (ví dụ: đường viền địa lý trên bản đồ), chúng tôi sử dụng một tính năng phần cứng đồ họa mới có tên Target Rasterization, hay TIR.

TIR cho phép Direct2D dành ít chu kỳ CPU hơn cho việc xử lý, do đó, nó có thể đưa ra các hướng dẫn vẽ cho GPU nhanh hơn và hiệu quả hơn mà không làm giảm chất lượng hình ảnh. TIR có sẵn trong phần cứng GPU mới được thiết kế cho Windows 8 hỗ trợ DirectX 11.1.

Dưới đây là biểu đồ cho thấy sự cải thiện hiệu suất để hiển thị hình học chống răng cưa từ nhiều tệp SVG trên GPU DirectX 11.1 hỗ trợ TIR: [snipped]

Chúng tôi đã hợp tác chặt chẽ với các đối tác phần cứng đồ họa [đọc AMD] để thiết kế TIR. Cải tiến mạnh mẽ đã được thực hiện vì sự hợp tác đó. Phần cứng DirectX 11.1 đã có mặt trên thị trường hiện nay và chúng tôi đang làm việc với các đối tác của chúng tôi để đảm bảo nhiều sản phẩm có khả năng TIR sẽ được cung cấp rộng rãi.

Tôi đoán đây là một trong những điều tuyệt vời mà Win 8 đã thêm vào mà hầu hết bị mất cho thế giới trong fiasco Metro UI ...

Có lẽ bởi vì lợi ích của nó không vượt quá chi phí.