ความสัมพันธ์ระหว่าง OpenGL, GLX, DRI และ Mesa3D คืออะไร


17

ฉันเริ่มทำการเขียนโปรแกรม 3D ระดับต่ำใน Linux ฉันมีประสบการณ์มากมายโดยใช้กราฟิก API ระดับสูงกว่า OpenInventor

ฉันรู้ว่ามันไม่จำเป็นอย่างยิ่งที่จะต้องตระหนักว่าสิ่งเหล่านี้เข้ากันได้อย่างไร แต่ฉันแค่อยากรู้อยากเห็น ฉันรู้ว่า OpenGL เป็นเพียงมาตรฐานสำหรับแอปพลิเคชันกราฟิก Mesa3D น่าจะเป็นการใช้งานโอเพ่นซอร์สของมาตรฐานนี้

ดังนั้น GLX และ DRI จะพอดีกับที่ใด เมื่อขุดลงบนวิกิพีเดียและเว็บไซต์ทั้งหมดเหล่านี้ฉันยังไม่พบคำอธิบายว่ามันเข้ากันได้อย่างไร การเร่งความเร็วฮาร์ดแวร์เกิดขึ้นที่ไหน ไดรเวอร์ที่เป็นกรรมสิทธิ์ต้องทำอะไรกับสิ่งนี้

คำตอบ:


15

ยกเว้น OpenGL ฉันไม่เคยใช้ห้องสมุดเหล่านั้น แต่ฉันจะพยายามเดาโดยอ่านหน้าวิกิพีเดียเหมือนที่คุณทำ

คุณดูเหมือนถูกต้องเกี่ยวกับเมซา นี่คือข้อมูลเพิ่มเติมที่เรามี:

"ระบบ X window เป็นระบบซอฟต์แวร์คอมพิวเตอร์และโปรโตคอลเครือข่ายที่ให้ GUI พื้นฐานสำหรับคอมพิวเตอร์เครือข่ายมันสร้างเลเยอร์นามธรรมที่เป็นฮาร์ดแวร์"

"GLX ช่วยให้โปรแกรมที่ต้องการใช้ OpenGL ทำได้ภายในหน้าต่างที่จัดทำโดย X Window System
GLX ประกอบด้วยสามส่วน:
- API ที่มีฟังก์ชั่น OpenGL
- ส่วนขยายของโปรโตคอล X ซึ่งช่วยให้ไคลเอนต์ส่ง 3D คำสั่งการเรนเดอร์ - ส่วนขยายของเซิร์ฟเวอร์ X ที่ได้รับคำสั่งการเรนเดอร์จากไคลเอนต์และส่งต่อไปยังไลบรารี OpenGL ที่ติดตั้ง
หากไคลเอนต์และเซิร์ฟเวอร์กำลังทำงานบนคอมพิวเตอร์เครื่องเดียวกันและการ์ดกราฟิก 3D เร่งความเร็ว ถูกบายพาสโดย DRI จากนั้นโปรแกรมไคลเอนต์ได้รับอนุญาตให้เข้าถึงฮาร์ดแวร์กราฟิกโดยตรง "

"โครงสร้างพื้นฐานการแสดงผลโดยตรง (DRI) เป็นอินเทอร์เฟซที่ใช้ในระบบ X Window เพื่ออนุญาตให้แอปพลิเคชันผู้ใช้เข้าถึงฮาร์ดแวร์วิดีโอโดยไม่ต้องการข้อมูลที่จะส่งผ่านเซิร์ฟเวอร์ X"

"Open Inventor เป็น API กราฟิก C ++ 3D ที่ออกแบบมาเพื่อมอบเลเยอร์การเขียนโปรแกรมที่สูงขึ้นสำหรับ OpenGL"

เพื่อให้สิ่งต่าง ๆ ง่ายขึ้นลองจินตนาการถึงการไหลของข้อมูลที่ง่ายขึ้น (และคำสั่ง) ที่เกิดขึ้นที่รายการและออกจากแต่ละ API เหล่านั้น ในตอนแรกเรามีโปรแกรมแอปพลิเคชันของคุณ (รวบรวมรหัส) ที่คุณเรียกใช้จากคอมพิวเตอร์ ในตอนท้ายเรามีภาพที่ปรากฏบนหน้าจอของคุณ

มีหลายกรณีที่ฉันจะยับยั้งคำตอบสำหรับคำถามเหล่านี้:
- คอมพิวเตอร์ของคุณมีกราฟิกการ์ด (GPU) หรือ CPU เท่านั้นเพื่อประมวลผลฟังก์ชั่นกราฟิกหรือไม่
- แอปพลิเคชันของคุณฝังอยู่ในหน้าต่างของระบบ x-window หรือไม่?
หากคุณใช้ระบบ x window จะเป็นการ "เซิร์ฟเวอร์ x" ทำงานบนคอมพิวเตอร์ของคุณหรือบนคอมพิวเตอร์เครื่องอื่นบนเครือข่ายหรือไม่?
ฉันจะสมมติว่าคุณมีไดรเวอร์สำหรับ GPU ของคุณถ้าคุณมีและคุณมี Mesa สำหรับการเรนเดอร์ซอฟต์แวร์)

สถานการณ์แรก: คุณเรียกใช้แอปพลิเคชันกราฟิกที่เขียนด้วย OpenInventor โดยไม่ใช้กับ X Window System และคุณไม่มีการ์ดกราฟิก การไหลเวียนของโปรแกรมจะค่อนข้างคล้ายกับ:

Your application
  ↓ (uses functions of)
OpenInventor
  ↓ (calls functions declared by)
OpenGL
  ↓ (redirects function calls to implementation defined by)
Mesa
  ↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
  ↓
3D Images on your screen

สิ่งที่เกิดขึ้นที่นี่เรียกว่า "การแสดงผลซอฟต์แวร์": คำสั่งกราฟิกไม่ได้รับการจัดการโดยฮาร์ดแวร์กราฟิกใด ๆ แต่โดย CPU ปกติของคุณโปรเซสเซอร์ที่ใช้งานซอฟต์แวร์โดยทั่วไป

สถานการณ์ที่สอง: ตอนนี้จินตนาการว่าด้วยเงื่อนไขเดียวกันกับข้างบนคุณมีการ์ดกราฟิก การไหลจะมีลักษณะเช่นนี้มากขึ้น:

Your application
  ↓ (uses functions of)
OpenInventor
  ↓ (calls functions declared by)
OpenGL
  ↓ (redirects function calls to implementation defined by)
Proprietary Drivers
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

สิ่งที่เกิดขึ้นตอนนี้เรียกว่า "การเร่งด้วยฮาร์ดแวร์" ซึ่งมักจะเร็วกว่าสถานการณ์แรก

สถานการณ์ที่สาม: ตอนนี้เราจะมาแนะนำขั้นตอนการทำงานของ X Window System หรืออย่างน้อยฉันก็คิดว่ามันเป็นไปตามบรรทัด Wikipedia ที่ฉันอ่าน
ลองลืมเกี่ยวกับฮาร์ดแวร์กราฟิกและ API ในขณะที่ การไหลควรมีลักษณะดังนี้:

Your application (X Window System sees it as an "X Client")
  ↓ (sends requests defined by the X Window System Core Protocol)
X Server
  ↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
  ↓
Windows or 2D images on your screen

โปรดทราบว่าเมื่อใช้ระบบ X Window หน้าจอและคอมพิวเตอร์ที่คุณเรียกใช้แอปพลิเคชันของคุณอาจไม่ได้เชื่อมต่อ "โดยตรง" แต่สามารถเชื่อมต่อผ่านเครือข่ายได้

สถานการณ์ที่สี่: สมมติว่าคุณต้องการเพิ่มการเรนเดอร์กราฟิก 3D แฟนซีลงในแอปพลิเคชันไคลเอนต์ X ของคุณจากตัวอย่างก่อนหน้า สำหรับฉันแล้วดูเหมือนว่าระบบ X Window นั้นไม่สามารถทำได้ในตอนแรกหรืออย่างน้อยก็จำเป็นต้องใช้รหัสที่ซับซ้อนมากเพื่อให้เทียบเท่ากับฟังก์ชั่น OpenGL API
โชคดีที่คุณสามารถใช้ GLX เพื่อเพิ่มการรองรับคำสั่ง OpenGL ในระบบ ตอนนี้คุณมี:

Your application
  ↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
  ↓ (convert your request to OpenGL commands)
OpenGL
  ↓ (redirects function calls to implementation defined by)
 ...

ตอนนี้คุณสามารถเชื่อมต่อลูกศรสุดท้ายกับหนึ่งหลังจาก "OpenGL" ในสถานการณ์แรก: คุณสามารถรับภาพ 3 มิติบนหน้าจอของคุณ!

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

...
  ↓
Mesa
  ↓ (forwards OpenGL commands)
DRI
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

และดูเหมือนว่าจะลัดวงจรการไหลเมื่อใช้ GLX เนื่องจากสภาพที่เซิร์ฟเวอร์และไคลเอนต์อยู่ในคอมพิวเตอร์เครื่องเดียวกันและคุณมี GPU ในกรณีนั้นกราฟของสถานการณ์สมมติที่สี่ของเราจะกลายเป็น:

Your application
  ↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
  ↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
  ↓
3D Images on your screen

แค่นั้นแหละ !
ตอนนี้จำไว้ว่าฉันไม่ใช่ผู้เชี่ยวชาญในสภาพแวดล้อม Unix ดังนั้นคำแนะนำที่ดีที่สุดของฉันคือการศึกษาเอกสารของแต่ละ API เหล่านั้นเพื่อให้รู้ว่าพวกเขาสามารถทำอะไรได้บ้าง
การรวมแผนภูมิก่อนหน้านี้เป็นแผนภูมิเดียวอาจทำให้เข้าใจได้ง่ายขึ้น ฉันปล่อยให้เรื่องนี้เป็นแบบฝึกหัดให้คุณ!


1
มันเป็นเพียงทฤษฎีที่ยึดตามการหักจากประโยคเพียงไม่กี่ประโยค มันไม่ใช่ความจริง
KawaiKx

8

OpenGL เป็นแพลตฟอร์มที่ไม่เชื่อเรื่องพระเจ้า นั่นหมายความว่า OpenGL API เป็นแพลตฟอร์มอิสระ

สถานะและบัฟเฟอร์ OpenGL ถูกรวบรวมโดยวัตถุนามธรรมซึ่งโดยทั่วไปเรียกว่าบริบท

แพลตฟอร์มการโฮสต์มีหน้าที่จัดเตรียม API บางอย่างเพื่อสร้างบริบท OpenGL สำหรับแพลตฟอร์มพื้นฐาน บน Windows มีรูทีน wgl * (Windows สำหรับ GL) บน Unix มีรูทีน glX * (GL สำหรับ X)

แท้จริงแล้ว GLX ไม่ได้เป็นเพียง API ที่อนุญาตให้แอปพลิเคชันสร้างบริบท OpenGL เพื่อใช้ OpenGL API

การดำเนินการ WGL / GLX ทั่วไปคือการสร้างหน้าต่างการสร้างบัฟเฟอร์นอกหน้าจอทำให้บริบทของ OpenGL เป็นปัจจุบันบนเธรดบัฟเฟอร์การวาดสลับ ...

DRI แทนเป็นเลเยอร์เคอร์เนลที่อนุญาตการสื่อสารโดยตรงกับการ์ดกราฟิกโดยผ่าน XServer ซึ่งเป็นการเร่งความเร็วแอปพลิเคชันโดยใช้รูทีน OpenGL


3

http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html

โครงสร้างพื้นฐานการแสดงผลโดยตรงหรือที่รู้จักกันว่า DRI เป็นกรอบการทำงานที่อนุญาตให้เข้าถึงฮาร์ดแวร์กราฟิกโดยตรงภายใต้ระบบ X Window ในลักษณะที่ปลอดภัยและมีประสิทธิภาพ ซึ่งรวมถึงการเปลี่ยนแปลงเซิร์ฟเวอร์ X ไปยังไคลเอนต์ไลบรารีหลายแห่งและเคอร์เนล (DRM, Direct Rendering Manager) การใช้งานที่สำคัญที่สุดสำหรับ DRI คือการสร้างการใช้งาน OpenGL ที่รวดเร็วซึ่งให้การเร่งด้วยฮาร์ดแวร์สำหรับ Mesa ไดรเวอร์เร่งความเร็ว 3 มิติหลายตัวได้รับการเขียนลงในข้อกำหนด DRI รวมถึงไดรเวอร์สำหรับชิปเซ็ตที่ผลิตโดย 3DFX, AMD (เดิมคือ ATI), Intel และ Matrox


2

ที่จะกล่าวง่ายๆก็คือ OpenGL เป็นประเภทไลบรารีกราฟิกและข้อมูลจำเพาะ เมซ่าเป็นฐานการปลูกรากฟันเทียม DRI เป็นระบบอินเตอร์เฟสฮาร์ดแวร์

เมซ่าโดยทั่วไปหมายถึงกรอบทั้งหมด อย่างไรก็ตามฉันจะสมมติว่าคุณกำลังพูดถึงไดรเวอร์ฮาร์ดแวร์ของ Mesa

DRI นั้นเป็นส่วนต่อประสานเคอร์เนลเพื่อจัดการกับฮาร์ดแวร์ ในทางเทคนิคสามารถใช้กับสิ่งอื่น ๆ ได้ แต่มันถูกสร้างขึ้นมาเพื่อ Mesa และส่วนใหญ่จะใช้สำหรับ Mesa

GLX เป็นวิธีการเชื่อมต่อกับ X ทั้งหมด !!

เพื่อให้เข้าใจว่าแต่ละส่วนคืออะไรคุณต้องรู้ว่ามันเข้ากันได้อย่างไร

โปรแกรมได้รับการออกแบบให้เชื่อมต่อกับห้องสมุด openGL ใด ๆ

GLX เป็นวิธีการติดต่อกับ OpenGL ด้วยหรือผ่าน X11 ขึ้นอยู่กับว่าคุณมีอินเทอร์เฟซ "โดยตรง" หรืออินเทอร์เฟซ "ทางอ้อม" ขึ้นอยู่กับว่าโปรแกรมของคุณจะกังวลเกี่ยวกับเรื่องนี้หรือไม่

libGL ค่อนข้างเป็นส่วนต่อประสานสำหรับสิ่งเหล่านี้ โดยทั่วไปแล้วจะให้บริการโดย Mesa หากคุณใช้ไดรเวอร์ Mesa

ในการตั้งค่าทางอ้อมมันจะเป็นดังนี้: Application Framework (เช่นแอปพลิเคชันที่เขียนยาก, Engine, หรือ Abstraction API) LibGL | ไดรเวอร์ Mesa DRI | ฮาร์ดแวร์

ในการกำหนดค่านี้ GLX จะใช้ด้านข้างเพื่อจัดการการเชื่อมต่อระหว่างการใช้ GL ของโปรแกรมและโปรแกรมอื่น ๆ นอกเหนือจากการโทรเฉพาะ GLX ที่ใช้ในการทำสิ่งต่าง ๆ ที่ต้องการการสื่อสาร X11 stack และเป็นโปรแกรมที่สนับสนุน (เช่น Window Managers) GLX นั้นไม่ได้ถูกแตะต้องเป็นส่วนใหญ่ ในการจัดเรียงนี้

นอกจากนี้คำสั่ง passthrough และหน่วยความจำแบบแบ่งใช้สามารถใช้เพื่อเพิ่มประสิทธิภาพเลเยอร์ในระบบนี้ ทั้งหมดนี้ช่วยลดเวลาในการตอบสนองและปรับปรุงความเร็วในการเข้าถึงฮาร์ดแวร์ นี่คือสิ่งที่คุณมักจะต้องการ

สำหรับทางอ้อมมันเป็น Application Framework ของคุณ LibGL (ฝั่งผู้ใช้) | LibGLX | LibGL (ด้าน X11) | Mesa Hardware Driver DRI | ฮาร์ดแวร์

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

การตั้งค่านี้สามารถทำงานกับ VM หลาย ๆ ตัวที่ใช้การ์ดวิดีโอร่วมกันหรือแม้แต่การเข้าถึงข้ามเครือข่ายด้วยเหตุนี้ หน่วยความจำที่ใช้ร่วมกันบางรูปแบบหรือหน่วยความจำแบบ "โคลน" แบบเสมือนสามารถใช้งานได้เนื่องจากส่วนขยายที่ใหม่กว่า แต่ไม่ใช่การเข้าถึงหน่วยความจำวิดีโอโดยตรงที่พบในโหมดการแสดงผลโดยตรง

ข้อเสียคือการใช้ไพพ์หรือซ็อคเก็ตเครือข่ายเพื่อเชื่อมต่อกับ X11 อาจช้าซึ่งอย่างน้อยที่สุดก็สามารถแนะนำ latencies สำหรับโปรแกรมที่ได้รับการปรับปรุงให้ดีที่สุดและที่แย่ที่สุดลดอัตราเฟรมอย่างรุนแรง

นี่คือประเภทของการตั้งค่าที่ดีกว่าสำหรับไคลเอนต์ในเครือข่ายการตั้งค่าที่ต้องการความปลอดภัยที่แข็งแกร่งยิ่งขึ้นและการตั้งค่าที่ระบบปฏิบัติการหลายระบบต้องใช้ฮาร์ดแวร์ร่วมกันโดยการทำงานผ่านสแต็ก GL เดียวกัน มันไกลจากที่ดีที่สุด แต่มันให้การเร่งฮาร์ดแวร์ในระดับหนึ่ง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.