하드웨어 가속 벡터 그래픽이 제거되지 않은 이유는 무엇입니까?

60fps에서 벡터 경로를 실시간으로 조작하는 앱을 개발 중이며 주제에 대한 정보가 거의 없다는 것에 놀랐습니다. 처음에는 CoreGraphics를 사용하여 아이디어를 구현하려고했지만 목적에 맞게 제대로 수행되지 않았습니다 . 그런 다음 OpenVG 라는 하드웨어 가속 벡터 그래픽에 대한 크로노스 표준이 있음을 알게되었으며, 친절한 영혼이 MonkVG 라는 OpenGL ES 반 구현을 작성했습니다 .

그러나 OpenVG가 매우 유용한 API라는 사실에도 불구하고 Khronos에 의해 다소 포기 된 것으로 보입니다. Wikipedia에 따르면 2011 년부터 실무 그룹은 "추가 표준화를 위해 정기적으로 회의를하지 않기로 결정했다"고 밝혔다. 내가 찾은 최고의 문서는 단지 하나의 참조 카드로 구성되어 있습니다. 또한 인터넷 어디에서나 OpenVG의 예는 거의 없습니다. 눈을 깜박이면서 수백 개의 OpenGL 자습서를 찾을 수 있지만 OpenVG가 눈에 띄게 누락 된 것 같습니다.

오늘날 급격히 증가하는 해상도의 세계에서 하드웨어 가속 벡터가 더 중요 할 것이라고 생각할 것입니다. 예를 들어 Qt 및 Flash에는 하드웨어 가속 벡터에 대한 체계가 있으며 많은 Adobe 도구에는 하드웨어 가속이 옵션으로 있습니다. 그러나 표준이 이미 존재할 때 바퀴가 재발 명되는 것처럼 보입니다!

실제 사용에 부적합한 OpenVG에 대해 누락 된 것이 있습니까? 아니면 표준이 제 시간에 잡히지 않았고 이제는 모호해질 운명입니까? 앞으로 하드웨어 가속 벡터 그래픽을위한 표준화 된 API를위한 공간이 있다고 생각하십니까, 아니면 전통적인 래스터 기반 기술을 사용하는 것이 더 쉬울까요? 아니면 벡터가 들어가기 전에 단순히 나가는가?

업데이트 : 답변 하단 참조

이 답변은 너무 늦었지만 다른 사람들에게 빛을 비추고 싶습니다 (특히 C ++ 표준위원회가 카이로를 표준으로 통합하려고합니다).

아무도 "가속 벡터 그래픽"에 관심이없는 이유는 GPU의 작동 방식 때문입니다. GPU는 대규모 병렬화 및 SIMD 기능을 사용하여 각 픽셀의 색상을 지정합니다. AMD는 일반적으로 64x64 8x8 픽셀 블록에서 작동 하지만 NVIDIA 카드는 일반적으로 32x32 4x4 픽셀 에서 작동 합니다 (아래 업데이트 참조)

3D 삼각형을 렌더링하는 경우에도 GPU는이 삼각형이 포함하는 전체 쿼드에서 작동합니다. 따라서 삼각형이 블록의 모든 8x8 픽셀 (또는 엔비디아의 경우 4x4)을 모두 덮지 않으면 GPU는 커버되지 않은 픽셀의 색상을 계산 한 다음 결과를 버립니다. 즉, 커버되지 않은 픽셀에 대한 처리 능력이 낭비된다. 이것은 낭비 적 인 것처럼 보이지만 엄청난 수의 GPU 코어와 쌍을 이루면 큰 3D 삼각형 을 렌더링하는 데 엄청나게 좋습니다 (자세한 내용 은 기본 래스터 라이저 최적화 ).

따라서 벡터 기반 래스터 화를 다시 살펴보면 선을 두껍게해도 큰 빈 공간이 있음을 알 수 있습니다. 처리 능력의 많은 낭비하고, 그래서, (주요 전력 소모의 원인, 종종 병목) 더 중요한 대역폭 당신은 팔의 두께 여러과의 수평 또는 수직 라인을 그리는 것,하지 않는 한 그리고 그것은 완벽에 정렬 8 픽셀 경계, 많은 처리 능력과 대역폭이 낭비됩니다.

"폐기물"의 양은 렌더링 할 선체를 계산하여 줄일 수 있지만 (NV_path_rendering처럼) GPU는 여전히 8x8 / 4x4 블록으로 제한됩니다 (또한 NVIDIA의 GPU 벤치 마크는 더 높은 해상도, 픽셀 _ 커버 / 픽셀 _ 폐기 비율로 더 잘 확장됩니다) 훨씬 낮습니다).

이것이 많은 사람들이 "벡터 hw 가속"에 신경 쓰지 않는 이유입니다. GPU는 단순히 작업에 적합하지 않습니다.

NV_path_rendering은 표준보다 예외이며 스텐실 버퍼를 사용하는 새로운 트릭을 소개했습니다. 압축을 지원하고 대역폭 사용량을 크게 줄일 수 있습니다.

그럼에도 불구하고, 나는 NV_path_rendering에 회의적이며, 일부 인터넷 검색 결과 OpenGL을 사용할 때 Qt가 권장되는 방식이 NVIDIA의 NV_path_rendering보다 훨씬 빠르다는 것을 보여줍니다. NV 경로 렌더링 달리 말하면 NVIDIA의 슬라이드는 XRender의 수량 죄송합니다.

Qt 개발자들은 "hw 가속을 사용한 모든 벡터 드로잉이 빠르다"고 주장하는 대신 HW 가속 벡터 드로잉이 항상 더 나은 것은 아니라는 점을 더 정직하게 인정합니다 ( Qt 그래픽 및 성능 – OpenGL 참조 ).

그리고 우리는 "라이브 편집"벡터 그래픽의 일부를 건드리지 않았습니다. 즉각 삼각형 스트립 생성이 필요합니다. 복잡한 svgs를 편집 할 때 실제로 심각한 오버 헤드가 추가 될 수 있습니다.

더 나은지 아닌지는 응용 프로그램에 따라 크게 다릅니다. 원래 질문 "이륙하지 않은 이유"에 관해서는, 지금 답변을 드리겠습니다 : 많은 단점과 제약이있어서 종종 많은 사람들이 회의적이고 회의적이지 않고 편견을 갖도록 편향시킬 수 있습니다. .

업데이트 : 언급 된 GPU가 64x64 및 32x32 블록에서 래스터 화되지 않고 8x8 = 64 및 4x4 = 16으로 래스터 화되므로 숫자가 완전히 기본이 아닌 것으로 나타났습니다. 이는 게시물의 결론을 거의 무효화합니다. 나중에이 게시물을 최신 정보로 업데이트하겠습니다.

나는 아무도이 답변에 쓰여진 "가속 벡터 그래픽"에 관심 이 없다고 생각하지 않는다 .

Nvidia는 공정한 관심을 갖고있는 것 같습니다. NV_path_rendering 의 수석 기술 담당자 인 킬 가르드 (NVpr)는 Nvidia의 부사장 인 Neil Trevett도 지난 몇 년간 NVpr을 홍보했습니다. 그의 talk1 , talk2 또는 talk3 참조하십시오 . 그리고 그것은 약간의 돈을 지불 한 것 같습니다. GTC14의 Kilgard의 슬라이드에 따르면,이 글을 쓰는 시점에서 NVpr은 이제 Google의 Skia (Google Chrome에서 사용됨)에서 베타 버전의 Adobe Illustrator CC (베타)에서 독립적으로 사용됩니다 . Kilgard 와 Adobe의 대화에 대한 비디오도 있습니다.. Intel에서 근무하는 Cairo 개발자도 NVpr에 관심이 있는 것 같습니다 . Mozilla / Firefox 개발자도 NVpr을 실험했으며 실제로이 FOSDEM14 토크쇼 에서 GPU 가속 벡터 그래픽에 관심이 있습니다.

마이크로 소프트는 Direct2D 를 만들었 기 때문에 공정한 관심을 갖고있다. Direct2D 는 상당히 광범위하게 사용된다 [앞서 언급 한 이야기에서 모질라 개발자를 믿는다면].

이제 원래의 질문에 도달하기 위해서는 경로 렌더링에 GPU를 사용하는 것이 간단하지 않은 몇 가지 기술적 이유가 있습니다. 경로 렌더링이 bog 표준 3D 정점 지오메트리와 어떻게 다른지 그리고 경로 렌더링의 GPU 가속이 사소하지 않은 이유에 대해 읽으려면 Kilgard는 FAQ와 같은 매우 좋은 게시물 을 가지고 있습니다.이 불행히도 OpenGL 포럼 어딘가에 묻혀 있습니다.

Direct2D, NVpr 및 이러한 작동 방식에 대한 자세한 내용 은 물론 NVpr에 중점을 둔 Kilgard의 Siggraph 2012 논문을 읽을 수 있지만 이전의 접근 방식을 조사하는데도 도움이됩니다. 빠른 해킹이 너무 잘 작동하지 않는다고 말하면 충분합니다 ... (PSE 질문의 텍스트가 언급 한 바와 같이)이 백서에서 논의되고 Kilgard의 초기 데모에서 볼 수 있듯이 이러한 접근 방식에는 성능 차이가 크게 있습니다. 이 비디오 . 또한 공식 NVpr 확장 문서 에는 몇 년 동안 여러 성능 조정 내용이 자세히 설명되어 있습니다.

Qt의 Zack Rusin의 2011 블로그 게시물 에서 말했듯이 NVpr이 2011 년 Linux (첫 번째 릴리스 구현)에서 그리 좋지 않았기 때문에 Goldberg의 대답으로 벡터 / 경로의 GPU 가속이 희망이 없다는 것을 의미하지는 않습니다 그로부터 유추 한 것으로 보인다. Kilgard는 실제로 블로그 게시물의 끝에 Qt의 빠른 코드보다 2 배에서 4 배의 개선 된 드라이버를 보여 주었으며 Rusin은 그 후 아무 말도하지 않았습니다.

Valve Corp.는 또한 GPU 가속 벡터 렌더링에 관심이 있지만 글꼴 / 글리프 렌더링과 관련하여 더 제한적입니다. 그들은 Siggraph 2007에서 발표 된 GPU 가속 부호있는 거리 필드 (SDF)를 사용하여 큰 글꼴 스무딩을 훌륭하고 빠르게 구현했습니다 . TF와 같은 게임에 사용됩니다. YouTube에 게시 된 기술 에 대한 비디오 데모가 있습니다 (그러나 누가 그랬는지 모르겠습니다).

SDF 접근법은 카이로와 판고 개발자 중 한 명이 GLyphy 형태로 약간의 개선을 보았습니다 . 저자는 linux.conf.au 2014에서 연설을했습니다.. 너무 오랫동안 보지 못했던 버전은 래스터가 아닌 벡터 공간에서 SDF 계산을 더 다루기 쉽게하기 위해 베 지어 곡선의 아크 스플라인 근사를 수행한다는 것입니다 (밸브는 후자를 수행했습니다). 그러나 호-스플라인 근사치에도 불구하고 계산 속도는 여전히 느 렸습니다. 그는 그의 첫 번째 버전이 3fps에서 실행되었다고 말했다. 그래서 그는 이제 "너무 멀리있는"것들에 대해 그리드 기반 컬링을 수행합니다. 이것은 LOD (세부 수준)의 형태로 보이지만 SDF 공간에 있습니다. 이 최적화를 통해 그의 데모는 60fps로 실행되었습니다 (아마 Vsync 제한). 그러나 그의 쉐이더는 엄청나게 복잡하며 하드웨어 및 드라이버의 한계를 뛰어 넘습니다. 그는 "모든 드라이버 / OS 조합마다 변경해야했다"는 내용을 따라 말했다. 또한 셰이더 컴파일러에서 중요한 버그를 발견했습니다. 그중 일부는 각각의 개발자에 의해 수정되었습니다. AAA 게임 타이틀 개발과 비슷합니다.

또 다른 방법으로, Microsoft는 Windows 8에서 사용 가능한 하드웨어 인 Direct2D 구현을 개선하기 위해 약간의 새로운 GPU 하드웨어를 시운전 / 지정한 것으로 보입니다 . 이를 TIR ( Target-Independent Rasterization )이라고하며 , 실제로는 실제로 어떤 일을하는지 약간 오도하는 이름 으로 Microsoft의 특허 출원에 나와 있습니다. AMD는 TIR이 2D 벡터 그래픽 성능을 약 500 % 향상 시켰다고 주장했다 . 그리고 케플러 GPU는이를 가지고 있지 않지만 AMD의 GCN 기반 GPU는 그렇지 않기 때문에 그들과 엔비디아 사이 에는 약간의 "전쟁" 이있었습니다. 엔비디아가 확인했습니다이것은 단순히 드라이버 업데이트가 제공 할 수있는 것이 아니라, 약간의 새로운 하드웨어라는 점입니다. Sinofsky의 블로그 게시물 에는 실제 TIR 벤치 마크를 포함하여 몇 가지 자세한 내용이 있습니다. 나는 일반적인 아이디어 비트 만 인용하고 있습니다 :

불규칙한 형상 (예 :지도의 지리적 경계)을 렌더링 할 때 성능을 개선하기 위해 TIR (Target Independent Rasterization)이라는 새로운 그래픽 하드웨어 기능을 사용합니다.

TIR을 사용하면 Direct2D가 테셀레이션에 더 적은 CPU주기를 소비 할 수 있으므로 시각적 품질을 저하시키지 않으면 서 GPU에보다 빠르고 효율적으로 드로잉 지침을 제공 할 수 있습니다. TIR은 DirectX 11.1을 지원하는 Windows 8 용으로 설계된 새로운 GPU 하드웨어에서 사용할 수 있습니다.

아래는 TIR을 지원하는 DirectX 11.1 GPU에서 다양한 SVG 파일의 앤티 앨리어싱 된 지오메트리 렌더링에 대한 성능 향상을 보여주는 차트입니다. [chart snipped]

TIR을 디자인하기 위해 그래픽 하드웨어 파트너 [AMD 읽기]와 긴밀히 협력했습니다. 그 파트너쉽으로 인해 크게 개선되었습니다. DirectX 11.1 하드웨어는 현재 시장에 나와 있으며 파트너와 협력하여 더 많은 TIR 가능 제품을 폭넓게 사용할 수 있도록 노력하고 있습니다.

나는 이것이 Metro UI fiasco에서 세계에서 가장 많이 잃어 버린 Win 8이 추가 한 멋진 것들 중 하나라고 생각합니다 ...

아마도 그 이점이 비용을 능가하지 않기 때문일 것입니다.