DRI және DRM жүйелері: графикалық үдеткіштерді басқару архитектурасы

Кіріспе

Framework

DRI іске асырылуы X Server және оған байланысты клиенттік кітапханалар, Mesa 3D және Direct Rendering Manager ядролық жүйесі арқылы шашыраңқы түрде таратылған. DRI клиенті – мысалы, «тікелей рендерингті» орындайтын X клиентіне – қазіргі бейнекартаны немесе графикалық адаптерді басқаруға қабілетті аппараттық «драйвер» қажет. Бұл DRI драйверлері әдетте клиентке динамикалық түрде байланыстырылатын ортақ кітапханалар түрінде ұсынылады. DRI 3D графикалық аппараттық құралдардың мүмкіндіктерін пайдалану үшін жасалғандықтан, кітапханалар клиенттерге әдетте OpenGL сияқты 3D API-дың аппараттық үдетілген нұсқасын ұсынады, оны 3D аппараттық өндірушінің өзі немесе Mesa 3D сияқты үшінші тарап жобасы ұсынады. X Server X11 протоколының кеңейтімін (DRI кеңейтімін) ұсынады, оны DRI клиенттері терезелік жүйемен және DDX драйверімен координациялау үшін пайдаланады. DDX драйверінің бір бөлігі ретінде, X Server процесі DRI клиенттерімен бірдей DRI драйверіне динамикалық түрде байланысуы жиі кездеседі, бірақ GLX кеңейтімін пайдаланып жанама рендерингті қамтамасыз ету үшін, X клиенттеріне аппараттық үдетілген 3D рендерингті ұсыну үшін (мысалы, тікелей рендерингті пайдалана алмайтын қашықтағы X клиенттері). 2D рендеринг үшін DDX драйвері сондай-ақ бірдей графикалық құрылғыны пайдаланатын DRI клиенттерін де ескеруі керек. Бейнекартаға немесе графикалық адаптерге қол жеткізуді Direct Rendering Manager (DRM) деп аталатын ядролық компонент реттейді. X Server-дің DDX драйвері де, әр X клиентінің DRI драйвері де графикалық жабдыққа қол жеткізу үшін DRM-ді пайдалануы керек. DRM графикалық жабдықтың ортақ ресурстарын – команда кезегі, карта тіркелгіштері, бейне жады, DMA қозғалтқыштары сияқты ресурстарды – синхрондауды қамтамасыз етеді, осылайша бірнеше бәсекелес пайдаланушы кеңістігі процестерінің бір мезгілде кіруінің бір-біріне кедергі келтірмеуін қамтамасыз етеді. DRM сондай-ақ негізгі қауіпсіздік механизмі ретінде қызмет етеді, ол кез келген X клиентіне 3D рендерингті орындау үшін қажеттіден артық аппараттық құралдарға қол жеткізуге рұқсат бермейді.

DRI implementation is scattered through the X Server and its associated client libraries, Mesa 3D and the Direct Rendering Manager kernel subsystem. the DRI client —for example, an X client performing "direct rendering"— needs a hardware specific "driver" able to manage the current video card or graphics adapter in order to render on it. These DRI drivers are typically provided as shared libraries to which the client is dynamically linked. Since DRI was conceived to take advantage of 3D graphics hardware, the libraries are normally presented to clients as hardware accelerated implementations of a 3D API such as OpenGL, provided by either the 3D hardware vendor itself or a third party such as the Mesa 3D free software project. the X Server provides an X11 protocol extension —the DRI extension— that the DRI clients use to coordinate with both the windowing system and the DDX driver. As part of the DDX driver, it's quite common that the X Server process also dynamically links to the same DRI driver that the DRI clients, but to provide hardware accelerated 3D rendering to the X clients using the GLX extension for indirect rendering (for example remote X clients that can't use direct rendering). For 2D rendering, the DDX driver must also take into account the DRI clients using the same graphics device. the access to the video card or graphics adapter is regulated by a kernel component called the Direct Rendering Manager (DRM). Both the X Server's DDX driver and each X client's DRI driver must use DRM to access to the graphics hardware. DRM provides synchronization to the shared resources of the graphics hardware —resources such as the command queue, the card registers, the video memory, the DMA engines, — ensuring that the concurrent access of all those multiple competing user space processes don't interfere with each other. DRM also serves as a basic security enforcer that doesn't allow any X client to access the hardware beyond what it needs to perform the 3D rendering.

DRI1

Бастапқы DRI архитектурасында, сол кездегі бейнекарталардың жады көлеміне байланысты, барлық DRI клиенттері мен X сервері бөліскен экранның алдыңғы және артқы буферлерінің (сондай-ақ қосымша тереңдік буфері мен штамп буферінің) бір ғана данасы болды. Түпкілікті шешім – DRI-дің рендерлеу буферлерін өңдеу тәсілін өзгерту болды, бұл жаңа операциялар жиынтығымен толығымен жаңа DRI кеңейтуіне және тікелей рендерлеу менеджерінде маңызды өзгерістерге әкелді. Ол алғаш рет XFree86 4.0 құрамында кеңінен қолжетімді болды және қазір X.Org серверінің бөлігі болып табылады. Қазіргі уақытта оны ашық кодты бағдарламалық қамтамасыз ету қауымдастығы қолдайды. DRI2 жұмысы 2007 жылы Х Дамушылар Саммитінде Кристиан Хёгсберг ұсынған идея негізінде басталды. Хёгсберг өзі жаңа DRI2 кеңейтуін және Mesa мен GLX-ке енгізілген өзгерістерді жазды. 2008 жылдың наурыз айында DRI2 көбінесе дайын болды, бірақ ол X.Org Server 1.5 нұсқасына енгізіле алмады және 2009 жылдың ақпан айынан бастап 1.6 нұсқасына дейін күтуге тура келді. DRI2 кеңейтуі ресми түрде 2009 жылдың қазан айындағы X11R7.5 нұсқасына қосылды. DRI2 протоколының алғашқы (2.0) нұсқасы 2009 жылдың сәуірінде жарияланды. Содан бері бірнеше түзетулер енгізілді, соңғысы 2012 жылдың шілдесіндегі 2.8 нұсқасы болды. DRI2-нің бірнеше шектеулеріне байланысты, Кит Паккард пен Эмма Анхолт 2012 жылғы X.Org Дамушылар Конференциясында DRI Next деп аталатын жаңа кеңейтуді ұсынды. DRI3 протоколының бірінші және жалғыз нұсқасы (1.0) 2013 жылдың қарашасында шығарылды.