ทำไมกราฟิกเวกเตอร์ที่เร่งด้วยฮาร์ดแวร์ไม่ได้ถูกถอดออก?

ฉันกำลังทำงานกับแอพที่เกี่ยวข้องกับการจัดการเวกเตอร์พา ธ แบบเรียลไทม์ที่ 60fps และฉันประหลาดใจมากที่มีข้อมูลเพียงเล็กน้อยในเรื่องนี้ ตอนแรกผมพยายามที่จะใช้ความคิดของฉันโดยใช้ CoreGraphics แต่มันก็ไม่ได้ดำเนินการอย่างเพียงพอเพื่อฉัน จากนั้นผมก็ค้นพบว่ามีความเป็นมาตรฐาน Khronos สำหรับฮาร์ดแวร์เร่งกราฟิกแบบเวกเตอร์ที่เรียกว่าOpenVGและขอบคุณจิตวิญญาณชนิดได้เขียน OpenGL ES กึ่งการดำเนินงานที่เรียกว่าMonkVG

แต่ข้อเท็จจริงที่ว่า OpenVG นั้นเป็น API ที่มีประโยชน์มาก แต่ดูเหมือนว่า Khronos จะถูกทอดทิ้งมากขึ้นหรือน้อยลง ตามวิกิพีเดียตั้งแต่ปี 2011 คณะทำงาน "ตัดสินใจที่จะ ... ไม่ต้องประชุมปกติ [sic] เพื่อให้ได้มาตรฐานมากขึ้น" เอกสารที่ดีที่สุดที่ฉันหาได้ประกอบด้วยบัตรอ้างอิงเพียงใบเดียว และยิ่งไปกว่านั้นยังมีตัวอย่างของ OpenVG แทบทุกที่บนอินเทอร์เน็ต ฉันสามารถค้นหาบทเรียนของ OpenGL หลายร้อยรายการได้ในพริบตา แต่ OpenVG ดูเหมือนจะหายไปอย่างชัดเจน

คุณคิดว่าเวกเตอร์ที่เร่งด้วยฮาร์ดแวร์จะมีความสำคัญมากกว่าในโลกปัจจุบันที่มีความละเอียดเพิ่มขึ้นอย่างรวดเร็วและดูเหมือนว่าหลาย บริษัท กำลังใช้วิธีการของตนเองในการทำสิ่งนี้ ตัวอย่างเช่น Qt และ Flash มีโครงร่างสำหรับเวกเตอร์ที่เร่งด้วยฮาร์ดแวร์และเครื่องมือของ Adobe หลายตัวมีการเร่งด้วยฮาร์ดแวร์เป็นตัวเลือก แต่ดูเหมือนว่าล้อจะเริ่มต้นใหม่เมื่อมาตรฐานมีอยู่แล้ว!

มีบางอย่างที่ฉันขาดเกี่ยวกับ OpenVG ที่ทำให้ไม่เหมาะกับการใช้งานจริงหรือไม่? หรือเป็นเพียงแค่ว่ามาตรฐานไม่ได้ทันเวลาและตอนนี้มันเป็นปลายทางสำหรับความสับสน? คุณคิดว่าจะมีที่ว่างสำหรับ API มาตรฐานสำหรับกราฟิกแบบเวกเตอร์ที่เร่งความเร็วฮาร์ดแวร์ในอนาคตหรือว่าจะง่ายกว่าที่จะใช้เทคนิคแบบแรสเตอร์แบบดั้งเดิมหรือไม่? หรือเวกเตอร์กำลังออกเดินทางก่อนที่พวกเขาจะเข้า?

อัปเดต:ดูที่ด้านล่างของการตอบกลับ

คำตอบนี้มาช้าไปหน่อย แต่ฉันหวังว่าจะส่องแสงสว่างให้ผู้อื่น (โดยเฉพาะตอนนี้ที่คณะกรรมการมาตรฐาน C ++ ต้องการรวมไคโรไว้ใน std):

เหตุผลที่ไม่มีใครสนใจ "กราฟิกแบบเวกเตอร์เร่ง" ที่แท้จริงเป็นเพราะการทำงานของ GPU GPU ทำงานโดยใช้การขนานขนาดใหญ่และความสามารถของ SIMD ในการทำสีแต่ละพิกเซล โดยทั่วไปแล้ว AMD จะทำงานเป็นกลุ่มขนาด64x64 8x8พิกเซลในขณะที่การ์ด NVIDIA โดยทั่วไปใช้งานได้ในขนาด32x32 4x4พิกเซล [ดูการอัปเดตที่ด้านล่าง]

แม้ว่าพวกมันจะแสดงผลเป็นสามเหลี่ยมสามมิติ แต่ GPU ก็ยังทำงานได้ทั้งสี่อย่างที่สามเหลี่ยมนี้ครอบคลุม ดังนั้นหากสามเหลี่ยมไม่ครอบคลุมพิกเซล 8x8 ทั้งหมดในบล็อก (หรือ 4x4 ในกรณีของ nvidia) GPU จะคำนวณสีของพิกเซลที่ไม่ได้เปิดออกแล้วละทิ้งผลลัพธ์ กล่าวอีกนัยหนึ่งกำลังการประมวลผลของพิกเซลที่ไม่ได้เปิดถูกทำลาย ขณะนี้ดูเหมือนว่าสิ้นเปลืองก็ทำงานได้อย่างไม่น่าเชื่อที่ดีสำหรับการแสดงผลขนาดใหญ่สามเหลี่ยม 3D เมื่อจับคู่กับจำนวนมากของแกน GPU (ข้อมูลรายละเอียดเพิ่มเติมได้ที่นี่: การเพิ่มประสิทธิภาพ rasterizer พื้นฐาน )

ดังนั้นเมื่อเรามองย้อนกลับไปที่การแรสเตอร์แบบเวกเตอร์คุณจะสังเกตได้ว่าเมื่อวาดเส้นแม้ว่ามันจะหนา แต่ก็มีพื้นที่ว่างขนาดใหญ่ จำนวนมากของพลังการประมวลผลที่สูญเสียและแบนด์วิดธ์ที่สำคัญกว่า (ซึ่งเป็นสาเหตุสำคัญของการใช้พลังงานและมักจะเป็นคอขวด) ดังนั้นถ้าคุณกำลังวาดเส้นแนวนอนหรือแนวตั้งที่มีหลายความหนาของ 8, และมันสมบูรณ์สอดคล้องไป ขอบเขต 8 พิกเซลพลังการประมวลผลและแบนด์วิดธ์จำนวนมากจะสูญเปล่า

จำนวนของ "ขยะ" สามารถลดลงได้โดยการคำนวณฮัลล์เพื่อแสดงผล (เช่นเดียวกับ NV_path_rendering) แต่ GPU ยัง จำกัด อยู่ที่บล็อก 8x8 / 4x4 (อาจเป็นเกณฑ์มาตรฐาน GPU ของ NVIDIA ที่ดีขึ้นโดยมีความละเอียดสูงกว่า ต่ำกว่ามาก)

นี่คือสาเหตุที่หลายคนไม่สนใจแม้แต่เรื่อง "การเร่งเวกเตอร์ hw" GPUs นั้นไม่เหมาะสำหรับงาน

NV_path_rendering เป็นข้อยกเว้นมากกว่าปกติและพวกเขาได้แนะนำเคล็ดลับใหม่ของการใช้ stencil buffer; ซึ่งรองรับการบีบอัดและสามารถลดการใช้แบนด์วิดท์ได้อย่างมาก

อย่างไรก็ตามฉันยังคงขี้ระแวงของ NV_path_rendering และมีบิตของ googling แสดงให้เห็นว่า Qt เมื่อใช้ OpenGL (aka วิธี Recomended) เป็นอย่างเร็วกว่า NV_path_rendering ของ NVIDIA: เส้นทาง NV แสดงผล ในคำอื่น ๆ ภาพนิ่งของ NVIDIA เป็น "บังเอิญ" เปรียบเทียบรุ่น XRender ของ Qt อ๊ะ

แทนที่จะเถียงว่า "การวาดเวกเตอร์ทุกอย่างที่มีความเร่ง hw เร็วขึ้น" นักพัฒนา Qt นั้นซื่อสัตย์กว่าการยอมรับการวาดเวกเตอร์ HW ที่เร่งขึ้นนั้นไม่ได้ดีกว่าเสมอไป (ดูวิธีการเรนเดอร์ทำงานอธิบาย: กราฟิก Qt และประสิทธิภาพ - OpenGL )

และเราไม่ได้สัมผัสส่วนหนึ่งของกราฟิกแบบเวกเตอร์ "การแก้ไขสด" ซึ่งต้องการการสร้างแถบสามเหลี่ยมในทันที เมื่อแก้ไข svgs ที่ซับซ้อนสิ่งนี้อาจเพิ่มค่าใช้จ่ายที่ร้ายแรง

ไม่ว่าจะดีกว่าหรือไม่ก็ขึ้นอยู่กับแอพพลิเคชั่น สำหรับคำถามเดิมของคุณ "ทำไมมันถึงไม่ถอด" ฉันหวังว่าตอนนี้จะได้รับคำตอบ: มีข้อเสียและข้อ จำกัด มากมายที่ต้องคำนึงถึงบ่อยครั้งทำให้คนจำนวนมากสงสัย .

อัปเดต:ฉันได้รับการชี้ให้เห็นว่าตัวเลขนั้นปิดฐานอย่างสมบูรณ์เนื่องจาก GPU ที่กล่าวมาไม่ได้ทำการ rasterize ในบล็อก 64x64 & 32x32 แต่แทนที่จะเป็น 8x8 = 64 และ 4x4 = 16 สิ่งนี้ค่อนข้างเป็นข้อสรุปของโพสต์ ฉันจะอัปเดตโพสต์นี้ในไม่ช้าพร้อมด้วยข้อมูลที่ทันสมัยมากขึ้น

ฉันไม่คิดว่ามันเป็นความจริงที่ไม่มีใครสนใจ "กราฟิกแบบเวกเตอร์เร่ง"ตามที่เขียนไว้ในคำตอบนี้

Nvidia ดูเหมือนว่าจะสนใจพอสมควร นอกจาก Kilgard ซึ่งเป็นผู้นำทางเทคนิคในNV_path_rendering (ต่อจากนี้ไป NVpr เพื่อประหยัดนิ้วของฉัน) ประธาน Khronos, Neil Trevett ซึ่งเป็นรองประธานที่ Nvidia ได้เลื่อนตำแหน่ง NVpr ให้มากที่สุดเท่าที่จะทำได้ในสองสามปีที่ผ่านมา เห็นเขาtalk1 , talk2หรือtalk3 และดูเหมือนว่าจะต้องจ่ายออกไปเล็กน้อย ตามเวลาของการเขียนนี้ตอนนี้ NVpr ถูกใช้ใน Skia ของ Google (ซึ่งจะใช้ใน Google Chrome) และเป็นอิสระ [ของ Skia] ในเวอร์ชันเบต้าของ Adobe Illustrator CC (เบต้า) ตามสไลด์ของKilgardที่GTC14 ; นอกจากนี้ยังมีวิดีโอพูดถึง: KilgardและAdobe. ผู้พัฒนาไคโร (ผู้ที่ทำงานให้กับ Intel) ก็มีความสนใจใน NVpr เช่นกัน Mozilla / Firefox devs ยังได้ทดลองกับ NVpr และพวกเขาสนใจจริง ๆ เกี่ยวกับ GPU ที่เร่งกราฟิกเวกเตอร์โดยทั่วไปในฐานะทอล์คโชว์FOSDEM14นี้

Microsoft ยังให้ความสำคัญกับเรื่องนี้เพราะพวกเขาสร้างDirect2Dซึ่งใช้กันอย่างแพร่หลายพอสมควร [ถ้าคุณเชื่อว่า Mozilla dev จากคำพูดที่กล่าวมาแล้ว]

ทีนี้มาถึงประเด็นของคำถามเดิม: มีเหตุผลทางเทคนิคบางประการที่ทำให้การใช้ GPU ในการเรนเดอร์เส้นทางไม่ตรงไปตรงมา หากคุณต้องการที่จะอ่านเกี่ยวกับวิธีการแสดงผลเส้นทางที่แตกต่างจากที่ลุ่มมาตรฐานจุดสุดยอด 3 มิติเรขาคณิตและสิ่งที่ทำให้เร่ง GPU ของเส้นทางการแสดงผลที่ไม่น่ารำคาญแล้วKilgard มีดีมากคำถามที่พบบ่อยเช่นโพสต์ซึ่งเป็นที่น่าเสียดายที่ฝังอยู่ที่ไหนสักแห่งในฟอรั่ม OpenGL

สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธี Direct2D, NVpr และงานดังกล่าวคุณสามารถอ่านบทความ Siggraph 2012 ของ Kilgardซึ่งแน่นอนว่าจะเน้นไปที่ NVpr แต่ก็มีงานสำรวจที่ดีเช่นกัน พอจะพูดได้ว่าแฮ็คด่วนไม่ทำงานได้ดีเกินไป ... (ตามที่ระบุในคำถามของ PSE) มีวิธีการที่แตกต่างกันอย่างมีนัยสำคัญระหว่างวิธีการเหล่านี้ตามที่กล่าวไว้ในบทความนั้นและแสดงในการสาธิตแรกของคิลการ์ดวิดีโอนี้ ฉันควรทราบด้วยว่าเอกสารนามสกุล NVpr อย่างเป็นทางการนั้นมีรายละเอียดการปรับประสิทธิภาพหลายครั้งในช่วงหลายปีที่ผ่านมา

เพียงเพราะ NVpr ไม่ค่อยดีใน ​​Linux ในปี 2011 (ในการนำไปใช้ครั้งแรก) เนื่องจากบล็อกโพสต์ 2011ของ Zack Rusin ของ Qt กล่าวว่าไม่ได้หมายความว่าการเร่งความเร็ว GPU ของเวกเตอร์ / เส้นทางนั้นสิ้นหวังตามคำตอบของ Mr. Goldberg ดูเหมือนจะอนุมานจากที่ ในความเป็นจริงแล้ว Kilgard ตอบกลับไปยังจุดสิ้นสุดของบล็อกโพสต์พร้อมกับไดรเวอร์ที่อัพเดตซึ่งแสดงการปรับปรุง 2x-4x สำหรับโค้ดที่เร็วขึ้นของ Qt และ Rusin ไม่ได้พูดอะไรเลยหลังจากนั้น

Valve Corp. ให้ความสำคัญกับการเรนเดอร์เวกเตอร์ที่ใช้ GPU เป็นหลัก แต่ก็มีข้อ จำกัด ที่เกี่ยวข้องกับการเรนเดอร์แบบอักษร / glyph พวกเขามีการใช้ฟอนต์ขนาดใหญ่ที่ราบรื่นและรวดเร็วโดยใช้ฟิลด์ที่มีการเร่งความเร็วด้วย GPU (SDF) ที่ Siggraph 2007ซึ่งใช้ในเกมของพวกเขาเช่น TF; มีวิดีโอสาธิตเทคนิคที่โพสต์บน YouTube (แต่ฉันไม่แน่ใจว่าใครเป็นคนทำ)

วิธีการ SDF ได้เห็นการปรับแต่งโดยหนึ่งใน บริษัท ไคโร & pango devs ในรูปแบบของGLyphy ; ผู้เขียนให้พูดคุยที่ linux.conf.au 2014. รุ่นที่ยาวเกินไปไม่ได้ดูคือเขาใช้การประมาณส่วนโค้งของเส้นโค้ง Bezier เพื่อทำให้การคำนวณ SDF นั้นง่ายขึ้นในเวกเตอร์ (แทนที่จะเป็นแบบแรสเตอร์) (Valve ทำแบบหลัง) แต่ถึงแม้จะมีการประมาณส่วนโค้ง - ส่วนโค้งการคำนวณก็ยังช้า เขาบอกว่าเวอร์ชั่นแรกของเขาวิ่งที่ 3 เฟรมต่อวินาที ดังนั้นตอนนี้เขาจึงเลือกสรรแบบกริดสำหรับบางสิ่งที่ "อยู่ไกลเกินไป" ซึ่งดูเหมือนว่ารูปแบบของ LOD (ระดับของรายละเอียด) แต่ในพื้นที่ SDF ด้วยการเพิ่มประสิทธิภาพนี้การสาธิตของเขาทำงานที่ 60 fps (และอาจเป็นข้อ จำกัด Vsync) อย่างไรก็ตามเครื่องเคลือบของเขามีความซับซ้อนอย่างเหลือเชื่อและผลักดันขีด จำกัด ของฮาร์ดแวร์และไดรเวอร์ เขาพูดอะไรบางอย่างตาม: "สำหรับชุดไดรเวอร์ / ระบบปฏิบัติการทุกครั้งที่เราต้องเปลี่ยนสิ่งต่าง ๆ " นอกจากนี้เขายังพบข้อบกพร่องที่สำคัญในคอมไพเลอร์ shader บางส่วนถูกแก้ไขโดย devs ที่เกี่ยวข้อง ฟังดูคล้ายกับการพัฒนาเกม AAA ...

บนตะปูอีกก็ปรากฏว่าไมโครซอฟท์ได้รับหน้าที่ / ระบุนิด ๆ หน่อย ๆ ของฮาร์ดแวร์ GPU ใหม่ในการปรับปรุงการดำเนินงานของพวกเขาด้วย Direct2D, ฮาร์ดแวร์ซึ่งถูกใช้โดย Windows 8 ถ้ามี นี้เรียกว่าเป้าหมายอิสระแรสเตอร์ ( TIR ) ชื่อซึ่งเป็นบิตทำให้เข้าใจผิดเป็นสิ่งที่สิ่งที่จริงดูเหมือนว่าจะทำซึ่งจะสะกดออกในการยื่นขอรับสิทธิบัตรไมโครซอฟท์ เอเอ็มดีอ้างว่าTIR ปรับปรุงประสิทธิภาพการทำงานในกราฟิกแบบเวกเตอร์ 2D โดยบางส่วน 500% และมี"สงครามคำศัพท์"ระหว่างพวกเขากับ Nvidia เพราะ Kepler GPU ไม่ได้มีในขณะที่ GPU ที่ใช้ GCN ของ AMD ทำ Nvidia ยืนยันแล้วว่านี่เป็นฮาร์ดแวร์ใหม่เล็กน้อยไม่ใช่แค่บางอย่างที่ไดรเวอร์อัพเดตสามารถให้ได้ โพสต์บล็อกของ Sinofskyมีรายละเอียดเพิ่มเติมเล็กน้อยรวมถึงมาตรฐานที่เป็นจริงของ TIR ฉันอ้างถึงเพียงบิตความคิดทั่วไป:

เพื่อปรับปรุงประสิทธิภาพเมื่อแสดงผลรูปทรงเรขาคณิตที่ผิดปกติ (เช่นเส้นขอบทางภูมิศาสตร์บนแผนที่) เราใช้คุณลักษณะฮาร์ดแวร์กราฟิกใหม่ที่เรียกว่า Target Independent Rasterization หรือ TIR

TIR ช่วยให้ Direct2D ใช้รอบ CPU น้อยลงในการทำเทสเซลเลชันดังนั้นจึงสามารถให้คำแนะนำในการวาดภาพให้กับ GPU ได้อย่างรวดเร็วและมีประสิทธิภาพโดยไม่ลดทอนคุณภาพของภาพ TIR พร้อมใช้งานในฮาร์ดแวร์ GPU ใหม่ที่ออกแบบมาสำหรับ Windows 8 ที่รองรับ DirectX 11.1

ด้านล่างนี้เป็นแผนภูมิแสดงการปรับปรุงประสิทธิภาพสำหรับการเรนเดอร์เรขาคณิตเชิงลบจากไฟล์ SVG ที่หลากหลายบน DirectX 11.1 GPU ที่รองรับ TIR: [แผนภูมิ snipped]

เราทำงานอย่างใกล้ชิดกับพันธมิตรฮาร์ดแวร์กราฟิกของเรา [อ่าน AMD] เพื่อออกแบบ TIR การปรับปรุงที่น่าทึ่งได้เกิดขึ้นเนื่องจากความเป็นหุ้นส่วนนั้น ฮาร์ดแวร์ DirectX 11.1 มีวางจำหน่ายแล้ววันนี้และเรากำลังทำงานร่วมกับคู่ค้าของเราเพื่อให้แน่ใจว่าผลิตภัณฑ์ที่มีความสามารถ TIR เพิ่มเติมจะสามารถใช้ได้ในวงกว้าง

ฉันเดาว่านี่เป็นหนึ่งในสิ่งที่ดีที่ Win 8 เสริมซึ่งส่วนใหญ่จะหายไปจากโลกในความล้มเหลวของ Metro UI ...

อาจเป็นเพราะผลประโยชน์ไม่ได้มีค่าเกินดุล