다이렉트 렌더링 인프라스트럭처

Direct Rendering Infrastructure
DR-1.0
원저작자Precision Insight, 텅스텐 그래픽스
개발자freedesktop.org
초기 릴리즈1998년 8월, 24년 전(1998-08)[1]
안정된 릴리스
2.4.x / 2009년2월
기입처C
플랫폼POSIX
유형프레임워크/API
면허증.MIT 및 기타 라이선스[2]
웹 사이트dri.freedesktop.org
DR-2.0
원저작자크리스티안 호그스버그 외
개발자freedesktop.org
초기 릴리즈2008년 9월 4일, 13년 전(2008-09-04)[3]
안정된 릴리스
2.8 / 2012년 7월 11일, 10년 전(2012-07-11)[4]
기입처C
플랫폼POSIX
유형프레임워크/API
면허증.MIT 및 기타 라이선스[2]
웹 사이트dri.freedesktop.org
DR-3.0
원저작자키스 패커드 외
개발자freedesktop.org
초기 릴리즈2013년 11월 1일, 8년 전(2013-11-01)[5]
안정된 릴리스
1.0 / 2013년 11월 1일, 8년 전(2013-11-01)[5]
기입처C
플랫폼POSIX
유형프레임워크/API
면허증.MIT 및 기타 라이선스[2]
웹 사이트dri.freedesktop.org
2개의 그래픽 하드웨어 드라이버가 있습니다.하나는 X 디스플레이 서버 내에 있습니다.이 드라이버는 여러 가지 디자인이 있습니다.현재의 것은, DIX(디바이스 의존형 X)와 DDX(디바이스 의존형 X)의 2개의 부분으로 분할됩니다.
Glamor는 X서버를 심플하게 합니다.libGL-fglrx-glx는 전용 바이너리 BLOB 대신 Radeon 오픈 소스 드라이버의 libDRM을 사용할 수 있습니다.
렌더링 계산은 OpenGL을 통해 GPU에 아웃소싱되어 실시간으로 이루어집니다.DRI는 접근 및 부기를 규제합니다.

Direct Rendering Infrastructure(DR; 다이렉트 렌더링 인프라스트럭처)는 권한이 없는 사용자 공간 프로그램이 다른 [6]프로그램과 충돌하지 않고 그래픽 하드웨어에 명령을 실행할 수 있는 최신 Linux 그래픽 스택으로 구성된 프레임워크입니다.DRI의 주된 용도는 OpenGL의 Mesa 구현을 위한 하드웨어 액셀러레이션을 제공하는 것입니다.DRI는 디스플레이 서버를 [7]실행하지 않고 프레임 버퍼 콘솔에서 OpenGL 액셀러레이션을 제공하도록 조정되었습니다.

DRI 실장은 X Server 및 관련 클라이언트 라이브러리, Mesa 3D 및 Direct Rendering Manager 커널 [6]서브시스템에 분산되어 있습니다.모든 소스 코드는 무료 소프트웨어입니다.

개요

기존의 X Window System 아키텍처에서 X Server는 그래픽 하드웨어에 독점적으로 액세스할 수 있는 유일한 프로세스이며, 따라서 프레임 버퍼에서 실제 렌더링을 수행하는 프로세스입니다.X 클라이언트는 X 서버와 통신하여 렌더링 명령어를 디스패치하기만 하면 됩니다.이러한 명령어는 하드웨어에 의존하지 않습니다.즉, X11 프로토콜은 그래픽 디바이스를 추상화하는 API를 제공하므로 X 클라이언트가 기본 하드웨어의 세부 사항을 알거나 걱정할 필요가 없습니다.하드웨어 고유의 코드는, 디바이스 의존형 X내에 있습니다.X 서버는 비디오 카드 또는 그래픽 어댑터의 각 타입을 관리하는 부분이며, 비디오 드라이버 또는 그래픽 드라이버라고도 불립니다.

3D 렌더링의 등장으로 이 아키텍처의 한계가 드러났습니다.3D 그래픽스 애플리케이션은 대량의 명령어와 데이터를 생성하는 경향이 있습니다.이러한 데이터는 모두 렌더링을 위해 X서버에 디스패치해야 합니다.X 클라이언트와 X 서버 간의 프로세스 간 통신(IPC) 양이 증가함에 따라 X 드라이버 개발자는 최신 그래픽 카드의 3D 하드웨어 기능을 활용하려면 새로운 IPC 없는 아키텍처가 필요하다는 결론을 내릴 정도로 3D 렌더링 성능이 저하되었습니다.X 클라이언트는 서드파티 프로세스에 의존하지 않고 그래픽 하드웨어에 직접 액세스 할 수 있어야 합니다.이것에 의해, 모든 IPC 오버헤드가 삭감됩니다.이 접근방식은 기존의 X 아키텍처가 제공하는 "간접 렌더링"과 달리 "직접 렌더링"이라고 불립니다.Direct Rendering Infrastructure는 처음에 X 클라이언트가 이 "Direct Rendering" 방식을 사용하여 3D 렌더링을 수행할 수 있도록 개발되었습니다.

DRI를 사용하여 X [3]클라이언트 내에서 가속화된 2D 다이렉트 렌더링을 구현하는 것을 막을 수 없습니다.2D 간접 렌더링 성능이 충분했기 때문에 누구도 그렇게 할 필요가 없었습니다.

소프트웨어 아키텍처

Direct Rendering Infrastructure의 기본 아키텍처에는 다음 3가지 [8]주요 구성요소가 포함됩니다.

  • 「다이렉트 렌더링」을 실행하는 X 클라이언트인 DRI 클라이언트에는, 현재의 비디오 카드 또는 그래픽 어댑터를 관리할 수 있는 하드웨어 고유의 「드라이버」가 필요합니다.이러한 DRI 드라이버는 일반적으로 클라이언트가 동적으로 링크되는 공유 라이브러리로 제공됩니다.DRI는 3D 그래픽 하드웨어를 이용하는 것으로 생각되었기 때문에 라이브러리는 일반적으로 3D 하드웨어 벤더 자체 또는 Mesa 3D 무료 소프트웨어 프로젝트와 같은 서드파티에 의해 제공되는 OpenGL과 같은 3D API의 하드웨어 가속 구현으로 고객에게 제공됩니다.
  • X 서버는 DRI 클라이언트가 윈도우 시스템 및 DDX [9]드라이버와 조정하기 위해 사용하는 X11 프로토콜 확장(DRI 확장)을 제공합니다.DDX 드라이버의 일부로서 X Server 프로세스는 DRI 클라이언트와 동일한 DRI 드라이버에 동적으로 연결되지만, 간접 렌더링을 위해 GLX 확장을 사용하여 X 클라이언트에 하드웨어 가속 3D 렌더링을 제공하는 것이 일반적입니다(예: 직접 렌더링을 사용할 수 없는 원격 X 클라이언트).2D 렌더링의 경우 DDX 드라이버는 동일한 그래픽 장치를 사용하는 DRI 클라이언트도 고려해야 합니다.
  • 비디오 카드 또는 그래픽 어댑터에 대한 액세스는 Direct Rendering Manager(DRM)[10]라고 불리는 커널 컴포넌트에 의해 규제됩니다.X Server의 DDX 드라이버와 각 X 클라이언트의 DR 드라이버는 모두 DRM을 사용하여 그래픽 하드웨어에 액세스해야 합니다.DRM은 그래픽 하드웨어의 공유 자원(명령어 큐, 카드 레지스터, 비디오 메모리, DMA 엔진 등)에 대한 동기화를 제공합니다.- 경쟁하는 여러 사용자 공간 프로세스의 동시 액세스가 서로 간섭하지 않도록 합니다.또한 DRM은 X 클라이언트가 3D 렌더링을 수행하는 데 필요한 수준 이상의 하드웨어에 액세스하는 것을 허용하지 않는 기본적인 보안 강화자 역할도 합니다.

드라이브 1

원래의 DRI 아키텍처에서는, 그 당시의 비디오 카드의 메모리 사이즈에 의해서, 모든 DRI 클라이언트와 X [11][12]서버에 의해서 공유되는 스크린 프론트 버퍼와 백 버퍼(보조 깊이 버퍼와 스텐실 버퍼도)의 단일 인스턴스가 있었습니다.모두 백버퍼에 직접 렌더링되어 수직 블랭크 간격에 [11]전면 버퍼와 스왑되었습니다.백 버퍼로 렌더링하려면 DRI 프로세스에서 렌더링이 [11][12]창용으로 예약된 영역까지 잘렸는지 확인해야 합니다.

X 서버와의 동기화는 신호와 [12]SAREA라고 불리는 공유 메모리 버퍼를 통해 이루어졌습니다.DRM 디바이스에의 액세스는 배타적이었기 때문에, DRI 클라이언트는 렌더링 조작의 개시시에 디바이스를 잠글 필요가 있었습니다.그 사이에 X Server를 포함한 디바이스의 다른 유저는 차단되어 양쪽의 [12]조작에 경합이 발생하지 않는 한 현재의 렌더링 조작이 종료될 때까지 기다려야 했습니다.또 다른 단점은 현재의 DRI 프로세스가 디바이스의 잠금을 해제한 후 작업이 메모리 할당을 유지하지 못했기 때문에 향후 작업을 위해 그래픽 메모리에 업로드된 텍스처 등의 데이터가 손실되어 그래픽 퍼포먼스에 큰 영향을 미친다는 것입니다.

현재 DRI1은 완전히 쓸모없는 것으로 간주되어 사용해서는 안 됩니다.

드라이브 2

Compiz와 같은 컴포지트 윈도 매니저의 인기가 높아짐에 따라 다이렉트 렌더링 인프라스트럭처는 X 클라이언트가 다이렉트 렌더링을 하는 동안 "오프스크린 픽스맵"으로의 리다이렉트도 지원할 수 있도록 재설계해야 했습니다.일반 X 클라이언트는 이미 X Server에서 제공하는 다른 pixmap(일명 오프스크린 pixmap)으로의 리다이렉션을 렌더 타깃으로 간주하고 있었지만 DRI 클라이언트는 렌더링을 공유 백버퍼에 직접 계속하여 컴포지팅창 [11][13]매니저를 바이패스했습니다.궁극적인 해결책은 DRI가 렌더 버퍼를 처리하는 방법을 변경하는 것이었고, 이로 인해 새로운 작업 세트를 통해 DRI 확장이 완전히 달라졌으며 Direct Rendering [3]Manager도 크게 변경되었습니다.새로운 확장자는 "DRY2"라는 이름이 붙었는데, 최신 버전은 아니지만 원래 DRY와 호환되지 않는 다른 확장자는 X Server 내에서 오랫동안 공존해 왔습니다.

DRI2에서는, 1개의 공유(백) 버퍼 대신에, 각 DRI 클라이언트는, 하드웨어 액셀러레이션을 사용해 윈도우 컨텐츠를 렌더링 하기 위해서, 독자적인 프라이빗 백[11][12] 버퍼와 관련하는 깊이 및 스텐실 버퍼를 취득합니다.다음으로 DRI 클라이언트는 VBLANK 간격으로 실제 프론트버퍼와 [12]스왑되는 최종 스크린백버퍼를 구성(빌드)하기 위한 소스 중 하나로 컴포지팅창 매니저에 의해 사용됩니다.

이러한 모든 새로운 버퍼를 처리하기 위해 Direct Rendering Manager는 새로운 기능, 특히 그래픽 메모리 매니저를 통합해야 했습니다.DRI2는 처음에는 실험적인 TTM 메모리 [11][13]매니저를 사용하여 개발되었지만 최종 DRM 메모리 [14]매니저로 선정된 후 GEM을 사용하도록 다시 작성되었습니다.또한 새로운 DRI2 내부 버퍼 관리 모델은 원래 DRI 구현에서 발생했던 두 가지 주요 성능 병목 현상을 해결했습니다.

  • DRI2 클라이언트는 렌더링에 사용하는 동안 DRM 디바이스 전체를 잠그지 않습니다.이는 각 클라이언트가 다른 [12]프로세스로부터 독립된 렌더 버퍼를 갖게 되었기 때문입니다.
  • DR2 클라이언트는 비디오 메모리에 독자적인 버퍼(질감, 정점 리스트 등)를 할당해, 필요한 만큼 유지할 수 있기 때문에, 비디오 메모리의 대역폭 소비량이 큰폭으로 삭감됩니다.

DRI2에서는 윈도우에 대한 개인 오프스크린 버퍼(백버퍼, 페이크 프론트버퍼, 깊이버퍼, 스텐실버퍼 등)의 할당은 X서버 [15][16]자체에 의해 이루어집니다.DRI 클라이언트는 DRI2GetBuffers 및 DRI2GetBuffers 등의 조작을 호출하여 이러한 버퍼를 취득하여 창으로 렌더링합니다.WithFormat을 DR2 [3]확장으로 사용할 수 있습니다.내부적으로 DR2는 GEM 이름(GEM API에 의해 제공되는 글로벌핸들 타입)을 사용하여 DRM 디바이스에 액세스 하는2개의 프로세스가 같은 버퍼를 참조할 수 있도록 합니다.이것에 의해, 이러한 버퍼에 「참조」를 X11 [16]프로토콜을 개입시켜 전달합니다.X 서버가 창의 렌더 버퍼 할당을 담당하는 이유는 GLX 확장을 통해 여러 X 클라이언트가 같은 [15]창에서 공동으로 OpenGL 렌더링을 수행할 수 있기 때문입니다.이와 같이 X 서버는 렌더링 프로세스 전체를 통해 렌더 버퍼의 전체 라이프사이클을 관리하고 언제 안전하게 재사용 또는 폐기할 수 있는지 파악합니다.윈도 사이즈가 변경되면 X 서버는 새로운 윈도 사이즈와 일치하는 새로운 렌더 버퍼를 할당하고 InvalidateBuffers 이벤트를 사용하여 창에 DRI 클라이언트의 렌더링 변경을 통지하여 새로운 [15]버퍼의 GEM 이름을 가져옵니다.

DR2 확장은 DRM 디바이스의 렌더링 및 버퍼 기능(DR2Authenticate)[3]을 사용하기 위해 사용하는 DRM 디바이스와 드라이버를 특정하거나(DR2Connect), X 서버에 의한 인증을 취득하는 등, DR 클라이언트에 다른 코어 조작을 제공합니다.화면에 렌더링된 버퍼의 표시는 DRI2CopyRegion 및 DRI2SwapBuffers 요청을 사용하여 수행됩니다.DR2CopyRegion은 가짜 프론트버퍼와 실제 프론트버퍼 간에 복사를 할 수 있지만 수직 블랭크 간격과의 동기화를 제공하지 않기 때문에 찢어지는 원인이 될 수 있습니다.한편 DRI2SwapBuffer는 지원되는 경우 후면 버퍼와 전면 버퍼 간에 VBLANK 동기화된 스왑을 수행하며,[3][15] 그렇지 않은 경우 두 버퍼의 크기가 같으면 복사(블릿)를 수행합니다.

드라이브 3

DRI2는 원래 DRI보다 크게 개선되었지만, 새로운 확장으로 몇 가지 새로운 [15][16]문제가 발생했습니다.2013년에는 이러한 [17]문제를 해결하기 위해 DRI3로 알려진 Direct Rendering Infrastructure의 세 번째 버전이 개발되었습니다.

DRI2와 비교한 DRI3의 주요 차이점은 다음과 같습니다.

  • DRI3 클라이언트는 X서버에 의존하지 않고 렌더 버퍼를 직접 할당합니다.[15][16]이것은 DRI2에서 지원되는 방법입니다.
  • DRI3는 파일 기술자를 [15][16]대신 사용하는 PRIME DMA-BUF에 기반한 보다 안전하고 다용도적인 것을 위해 DRI 클라이언트와 X 서버 간에 버퍼 객체를 전달하기 위한 GEM 이름(글로벌 GEM 핸들)에 기반한 오래된 안전하지 않은 GEM 버퍼 공유 메커니즘을 제거합니다.

클라이언트측의 버퍼 할당은, 복수의 GLX 애플리케이션이 같은 창에서 제휴해 렌더링 할 수 없게 되어, GLX 의 전제 조건을 깨뜨립니다.또, DRI 클라이언트는 라이프 타임을 통해서 자신의 버퍼를 담당할 수 있기 때문에, 많은 이점이 있습니다.예를 들어 DRI3 클라이언트는 렌더 버퍼의 크기가 항상 창의 현재 크기와 일치하도록 하기 때문에 DRI2에서 [15][16][18]창 크기 조정에 문제가 있는 클라이언트와 서버 간의 버퍼 크기 동기화가 부족하기 때문에 발생하는 아티팩트를 제거할 수 있습니다.DRI3 클라이언트는 X 서버가 렌더 [16]버퍼를 전송하기를 기다리는 여분의 라운드 트립을 저장하기 때문에 퍼포먼스도 향상됩니다.DRI3 클라이언트, 특히 컴포지터 윈도 매니저는 이전 프레임의 오래된 버퍼를 유지하고 이를 기반으로 창의 손상된 부분만 렌더링하여 다른 성능 [15][16]최적화로 사용할 수 있습니다.DRI3 확장은 DRI 클라이언트 드라이버와 DRM 커널 [15]드라이버 간에 직접 처리되므로 새로운 특정 버퍼 형식을 지원하기 위해 변경할 필요가 없습니다.한편, 파일 기술자를 사용하면 커널은 사용되지 않는 GEM 버퍼 오브젝트([15][16]참조하지 않음)를 안전하게 청소할 수 있습니다.

기술적으로 DRI3는 "DR3" 확장과 "Present"[17][19] 확장의 두 가지 다른 확장으로 구성됩니다.DRI3 확장의 주된 목적은 DRI 클라이언트와 X [18][19][20]서버 간에 직접 렌더링된 버퍼를 공유하는 메커니즘을 구현하는 것입니다.DRI 클라이언트는 렌더링 대상으로 GEM 버퍼 개체를 할당하고 사용하는 반면 X 서버는 "pixmap"이라는 X11 개체를 사용하여 이러한 렌더 버퍼를 나타냅니다.DRI3는 DRI3PixmapFromBuffer와 DRI3BufferFromPixmap의 2가지 조작을 제공합니다.하나는 GEM 버퍼 오브젝트('DRI 클라이언트스페이스' 내)에서 픽스맵을 작성하는 조작이며, 이제1개는 GEM 버퍼 오브젝트를 반대로 실행하여 XPIX [18][19][20]맵에서 취득하는 조작입니다.이러한 DRI3 동작에서는 GEM 버퍼 오브젝트는 GEM 이름이 아닌 DMA-BUF 파일 기술자로 전달됩니다.또, DRI3는, DRI 클라이언트와 X 서버간에 동기 오브젝트를 공유하는 방법을 제공해,[19] 양쪽 모두 공유 버퍼에의 시리얼화된 액세스를 가능하게 합니다.DRI2와는 달리 첫 번째 DRI3Open 조작(사용하는 DRM 디바이스의 파악을 요구해야 하는 모든 DRI3Open 조작)에서는 디바이스 노드의 파일명이 아닌 디바이스 노드에 이미 열려 있는 파일 기술자가 반환되며 X [18][19]서버가 사전에 필요한 인증 절차를 수행합니다.

DRI3는 렌더링된 버퍼를 화면에 표시하는 메커니즘을 제공하지 않지만 [20]이를 위해 다른 확장자(Present Extension)를 합니다.Present는 그 주요 태스크가 화면에 버퍼를 표시하는 것이기 때문에 이름이 붙여졌습니다.즉, 클라이언트애플리케이션에 [19]의해서 전달되는 렌더링 버퍼의 내용을 사용해 프레임 버퍼의 갱신을 처리합니다.화면 업데이트는 일반적으로 VBLANK 간격 동안 적절한 시간에 수행해야 합니다. 이는 찢김 등의 디스플레이 아티팩트를 방지하기 위함입니다.Present는 VBLANK [21]간격에 대한 화면 업데이트 동기화도 처리합니다.또한 이벤트를 사용하여 각 버퍼가 실제로 화면에 표시되는 순간을 X 클라이언트에 계속 알려주기 때문에 클라이언트는 렌더링 프로세스를 현재 화면 새로 고침 속도와 동기화할 수 있습니다.

Present는 화면 업데이트의 [21]소스로서 임의의 X픽스맵을 받아들입니다.pixmap은 표준 X 객체이기 때문에 Present는 직접 렌더링을 실행하는 DRI3 클라이언트뿐만 아니라 [18]어떤 방법으로든 pixmap 상의 X 클라이언트 렌더링에서도 사용할 수 있습니다.예를 들어 기존 GL 기반 이외의 대부분의 GTK+ 및 Qt 어플리케이션에서는 XRender를 사용하여 더블 버퍼링된 pixmap 렌더링을 수행했습니다.또한 이러한 응용 프로그램에서 현재 확장을 사용하여 효율적이고 지루하지 않은 화면 업데이트를 수행할 수 있습니다.이것이 Present가 DRI3의 [18]일부가 아닌 별도의 독립형 확장으로 개발된 이유입니다.

GL X 이외의 클라이언트가 VBLANK와 동기할 수 있는 것 외에 Present는 다른 이점을 가져옵니다.버퍼 [19]스왑에서는 Present가 DR2보다 효율적이기 때문에 DR3 그래픽스의 퍼포먼스가 향상됩니다.DRI2에서는 사용할 수 없었던 OpenGL 확장의 수가 현재 [19]Present에서 제공하는 새로운 기능을 기반으로 지원됩니다.

Present는 X 클라이언트에 2가지 주요 조작을 제공합니다.pixmap(Present Pixmap)의 일부 또는 모든 콘텐츠를 사용하여 창 영역을 갱신하고 클라이언트에 통지할 특정 창과 관련된 프레젠테이션이벤트 유형을 설정합니다(Present Select Input).[19][21]창이 X 클라이언트에 통지할 수 있는 프레젠테이션이벤트에는 3가지가 있습니다.보통 PresentPixmap에 대한 콜에서 진행 중인 프레젠테이션 조작이 완료된 경우(PresentCompleteNotify), PresentPixmap 조작에서 사용되는 pixmap이 재사용할 준비가 된 경우(PresentIdleNotify), 창 설정(대부분의 크기)입니다.변경(Present Configure Notify).[19][21]Present Pixmap 조작이 프론트버퍼에 직접 복사(블릿)를 실행할지, 백버퍼 전체를 프론트버퍼와 스왑할지는 DRI2에서와 같이 X 클라이언트를 명시적으로 선택하는 것이 아니라 현재 확장 구현의 내부 세부 사항입니다.

도입

ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 ~ Voodoo5, Matrox G200 ~ G400, SiS 300 시리즈, 인텔 i810 ~i965, Savage, Unichets를 통한 오픈 소스 DRI 드라이버 등 여러 개가 작성되었습니다.ATI나 Power를 포함한 일부 그래픽 벤더는 클로즈드 소스 DRI 드라이버를 작성하고 있습니다.VR 카이로

다양한 버전의 DRI는 Linux 커널, FreeBSD, NetBSD, OpenBSD, OpenSolaris 등 다양한 운영체제에 의해 구현되고 있습니다.

역사

이 프로젝트는 Precision Insight의 Jens Owen과 Kevin E. Martin에 의해 시작되었습니다(Silicon Graphics와 Red [1][22]Hat의 자금 지원).XFree86 4.0의[1][23] 일부로서 처음 널리 보급되었으며, 현재는 X의 일부입니다.조직 서버그것은 현재 자유 소프트웨어 커뮤니티에 의해 유지되고 있다.

DRI2에 대한 작업은 2007년 X Developers Summit에서 Christian Högsberg의 [24][25]제안으로 시작되었습니다.Högsberg는 Mesa와 GLX에 [26]대한 새로운 DRI2 확장과 수정 사항을 직접 작성했다.2008년 3월에는 DRI2가 거의 [27][28][29]완성되었지만 X가 되지 않았습니다.Org Server 버전 1.5로[14] 2009년 [30]2월부터 버전 1.6까지 기다려야 했습니다.DRI2 확장은 2009년 [31]10월의 X11R7.5 릴리스에 공식적으로 포함되었습니다.DRI2 프로토콜의 첫 번째 공개 버전(2.0)은 2009년 [32]4월에 발표되었습니다.이후 몇 가지 수정이 이루어졌으며 2012년 [4]7월부터 가장 최신 버전 2.8이 되었습니다.

DRI2의 몇 가지 제한으로 인해 DRI-Next라는 새로운 확장이 Keith Packard와 Emma Anholt에 의해 X에서 제안되었습니다.조직개발자회의 2012.[15]이 확장 기능은 Linux.conf.au [16][17]2013에서 DR3000으로 다시 제안되었습니다.DRI3 및 Present 확장 기능은 2013년에 개발되어 X에 통합되었습니다.Org Server 1.15 출시(2013년 [33][34]12월).DRI3 프로토콜의 최초이자 유일한 버전(1.0)은 2013년 [5]11월에 출시되었습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Owen, Jens. "The DRI project history". DRI project wiki. Retrieved 16 April 2016.
  2. ^ a b c Mesa DRI 라이선스 / 저작권 정보 - Mesa 3D 그래픽스 라이브러리
  3. ^ a b c d e f Høgsberg, Kristian (4 September 2008). "The DRI2 Extension - Version 2.0". X.Org. Retrieved 29 May 2016.
  4. ^ a b Airlie, Dave (11 July 2012). "[ANNOUNCE] dri2proto 2.8". xorg-announce (Mailing list).
  5. ^ a b c Packard, Keith (1 November 2013). "[ANNOUNCE] dri3proto 1.0". xorg-announce (Mailing list).
  6. ^ a b "Mesa 3D and Direct Rendering Infrastructure wiki". Retrieved 15 July 2014.
  7. ^ "DRI for Framebuffer Consoles". Retrieved January 4, 2019.
  8. ^ Martin, Kevin E.; Faith, Rickard E.; Owen, Jens; Akin, Allen (11 May 1999). "Direct Rendering Infrastructure, Low-Level Design Document". Retrieved 18 May 2016.
  9. ^ Owen, Jens; Martin, Kevin (11 May 1999). "DRI Extension for supporting Direct Rendering - Protocol Specification". Retrieved 18 May 2016.
  10. ^ Faith, Rickard E. (11 May 1999). "The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure". Retrieved 18 May 2016.
  11. ^ a b c d e f Packard, Keith (21 July 2008). "X output status july 2008". Retrieved 26 May 2016.
  12. ^ a b c d e f g Packard, Keith (24 April 2009). "Sharpening the Intel Driver Focus". Retrieved 26 May 2016.
  13. ^ a b Høgsberg, Kristian (8 August 2007). "Redirected direct rendering". Retrieved 25 May 2016.
  14. ^ a b Høgsberg, Kristian (4 August 2008). "Backing out DRI2 from server 1.5". xorg (Mailing list).
  15. ^ a b c d e f g h i j k l Packard, Keith (28 September 2012). "Thoughts about DRI.Next". Retrieved 26 May 2016.
  16. ^ a b c d e f g h i j Willis, Nathan (11 February 2013). "LCA: The X-men speak". LWN.net. Retrieved 26 May 2016.
  17. ^ a b c Packard, Keith (19 February 2013). "DRI3000 — Even Better Direct Rendering". Retrieved 26 May 2016.
  18. ^ a b c d e f Packard, Keith (4 June 2013). "Completing the DRI3 Extension". Retrieved 31 May 2016.
  19. ^ a b c d e f g h i j Edge, Jake (9 October 2013). "DRI3 and Present". LWN.net. Retrieved 26 May 2016.
  20. ^ a b c Packard, Keith (4 June 2013). "The DRI3 Extension - Version 1.0". Retrieved 30 May 2016.
  21. ^ a b c d Packard, Keith (6 June 2013). "The Present Extension - Version 1.0". Retrieved 1 June 2016.
  22. ^ Owen, Jens; Martin, Kevin E. (15 September 1998). "A Multipipe Direct Rendering Architecture for 3D". Retrieved 16 April 2016.
  23. ^ "Release Notes for XFree86 4.0". XFree86 Project. 7 March 2000. Retrieved 16 April 2016.
  24. ^ "X Developers' Summit 2007 - Notes". X.Org. Retrieved 7 March 2016.
  25. ^ Høgsberg, Kristian (3 October 2007). "DRI2 Design Wiki Page". xorg (Mailing list).
  26. ^ Høgsberg, Kristian (4 February 2008). "Plans for merging DRI2 work". xorg (Mailing list).
  27. ^ Høgsberg, Kristian (15 February 2008). "DRI2 committed". xorg (Mailing list).
  28. ^ Høgsberg, Kristian (31 March 2008). "DRI2 direct rendering". xorg (Mailing list).
  29. ^ Høgsberg, Kristian (31 March 2008). "DRI2 Direct Rendering". Retrieved 20 April 2016.
  30. ^ "Server 1.6 branch". X.org. Retrieved 7 February 2015.
  31. ^ "Release Notes for X11R7.5". X.Org. Retrieved 20 April 2016.
  32. ^ Høgsberg, Kristian (20 April 2009). "[ANNOUNCE] dri2proto 2.0". xorg-announce (Mailing list).
  33. ^ Packard, Keith. "[ANNOUNCE] xorg-server 1.14.99.901". X.org. Retrieved 9 February 2015.
  34. ^ Larabel, Michael. "X.Org Server 1.15 Release Has Several New Features". Phoronix. Retrieved 9 February 2015.

외부 링크

Wikimedia Commons에는 Direct Rendering Infrastructure와 관련된 미디어가 있습니다.