Misplaced Pages

#443556

124-503: DRI implementation is scattered through the X Server and its associated client libraries, Mesa 3D and the Direct Rendering Manager kernel subsystem. All of its source code is open-source software . In the classic X Window System architecture the X Server is the only process with exclusive access to the graphics hardware , and therefore the one which does the actual rendering on the framebuffer . All that X clients do

248-854: A PresentPixmap operation performs a direct copy ( blit ) onto the front buffer or a swap of the entire back buffer with the front buffer is an internal detail of the Present extension implementation, instead of an explicit choice of the X client as it was in DRI2. Several open source DRI drivers have been written, including ones for ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 through Voodoo5, Matrox G200 through G400, SiS 300-series, Intel i810 through i965, S3 Savage, VIA UniChrome graphics chipsets, and nouveau for Nvidia . Some graphics vendors have written closed-source DRI drivers, including ATI and PowerVR Kyro. The various versions of DRI have been implemented by various operating systems, amongst others by

372-431: A rendering operation. Other users of the device —including the X Server— were blocked in the meantime, and they had to wait until the lock was released at the end of the current rendering operation, even if it wouldn't be any conflict between both operations. Another drawback was that operations didn't retain memory allocations after the current DRI process released its lock on the device, so any data uploaded to

496-480: A GEM object with another process can convert its local GEM handle to a DMA-BUF file descriptor and pass it to the recipient, which in turn can get its own GEM handle from the received file descriptor. This method is used by DRI3 to share buffers between the client and the X Server and also by Wayland . In order to work properly, a video card or graphics adapter must set a mode —a combination of screen resolution , color depth and refresh rate —that

620-677: A Vulkan driver for their hardware the day the specification was officially released, but it was only mainlined in April and so became part of Mesa 12.0, released in July 2016. While already the i965 driver wasn't written according to the Gallium3D specifications, for the Vulkan driver it makes even less sense to flange it on top of Gallium3D. Similarly there is no technical reason to flange it with NIR, but yet Intel's employees implemented their Vulkan driver that way. It

744-525: A dedicated VRAM, in a suitable way, and to provide every conceivable feature in a memory manager for use with any type of hardware, led to an overly complex solution with an API far larger than needed. Some DRM developers thought that it wouldn't fit well with any specific driver, especially the API. When GEM emerged as a simpler memory manager, its API was preferred over the TTM one. But some driver developers considered that

868-454: A failed mode-setting process has to be undone ("rollback"). Atomic mode-setting allows one to know beforehand if certain specific mode configuration is appropriate, by providing mode testing capabilities. When an atomic mode is tested and its validity confirmed, it can be applied with a single indivisible (atomic) commit operation. Both test and commit operations are provided by the same new ioctl with different flags. Atomic page flip on

992-505: A graphical compositor, ...) have full access to the DRM API, including the privileged parts like the modeset API. Other user space applications that want to render or make GPGPU computations should be granted by the owner of the DRM device ("DRM Master") through the use of a special authentication interface. Then the authenticated applications can render or make computations using a restricted version of

1116-399: A kernel running in protected mode . The situation changed when Luc Verhaegen and other developers found a way to do the mode-setting natively instead of BIOS-based, showing that it was possible to do it using normal kernel code and laying the groundwork for what would become Kernel Mode Setting . In May 2007 Jesse Barnes ( Intel ) published the first proposal for a drm-modesetting API and

1240-494: A local GEM handle to a DMA-BUF file descriptor and another for the exact opposite operation. These two new ioctls were later reused as a way to fix the inherent unsafety of GEM buffer sharing. Unlike GEM names, file descriptors can not be guessed (they are not a global namespace), and Unix operating systems provide a safe way to pass them through a Unix domain socket using the SCM_RIGHTS semantics. A process that wants to share

1364-451: A new Linux version is going to be released. Torvalds, as top maintainer of the whole kernel, holds the last word on whether a patch is suitable or not for inclusion in the kernel. For historical reasons, the source code of the libdrm library is maintained under the umbrella of the Mesa project. In 1999, while developing DRI for XFree86 , Precision Insight created the first version of DRM for

SECTION 10

#1732891891444

1488-462: A number of extensions not part of any OpenGL or OpenGL ES version. 3rd Version 17.2 is available since September 2017 with some new OpenGL 4.6 features and velocity improvements in 3D for Intel and AMD. Only 1.4% of Tests fail for OpenGL 4.5 in Nouveau for Kepler. 4th Version 17.3 is ready since December 2017. Many improvements in many drivers are available. OpenGL 4.6 is nearly fully available (Spir-V

1612-447: A pixmap (in "X Server space") from a GEM buffer object (in "DRI client space"), and the other to do the reverse and get a GEM buffer object from an X pixmap. In these DRI3 operations GEM buffer objects are passed as DMA-BUF file descriptors instead of GEM names. DRI3 also provides a way to share synchronization objects between the DRI client and the X Server, allowing both a serialized access to

1736-507: A pixmap by any means. For example, most existing non- GL based GTK+ and Qt applications used to do double buffered pixmap rendering using XRender . The Present extension can also be used by these applications to achieve efficient and non-tearing screen updates. This is the reason why Present was developed as a separate standalone extension instead of being part of DRI3. Apart from allowing non-GL X clients to synchronize with VBLANK, Present brings other advantages. DRI3 graphics performance

1860-449: A proposal by Kristian Høgsberg . Høgsberg himself wrote the new DRI2 extension and the modifications to Mesa and GLX . In March 2008 DRI2 was mostly done, but it couldn't make into X.Org Server version 1.5 and had to wait until version 1.6 from February 2009. The DRI2 extension was officially included in the X11R7.5 release of October 2009. The first public version of the DRI2 protocol (2.0)

1984-509: A separate VRAM. For this reason, other DRM drivers have decided to expose to user-space programs the GEM API, but internally they implemented a different memory manager better suited for their particular hardware and memory architecture. The GEM API also provides ioctls for control of the execution flow (command buffers), but they are Intel-specific, to be used with Intel i915 and later GPUs. No other DRM driver has attempted to implement any part of

2108-484: A tight integration with the graphics memory manager is highly recommended. That's the main reason why the kernel mode-setting code was incorporated into DRM and not as a separate subsystem. To avoid breaking backwards compatibility of the DRM API, Kernel Mode-Setting is provided as an additional driver feature of certain DRM drivers. Any DRM driver can choose to provide the DRIVER_MODESET flag when it registers with

2232-399: A translation layer between a graphics API such as OpenGL and the graphics hardware drivers in the operating system kernel. The supported version of the different graphic APIs depends on the driver, because each hardware driver has its own implementation (and therefore status). This is especially true for the "classic" drivers, while the Gallium3D drivers share common code that tend to homogenize

2356-450: A unique 32-bit integer . GEM provides an operation flink to obtain a GEM name from a GEM handle. The process can then pass this GEM name (32-bit integer) to another process using any IPC mechanism available. The GEM name can be used by the recipient process to obtain a local GEM handle pointing to the original GEM object. Unfortunately, the use of GEM names to share buffers is not secure. A malicious third-party process accessing

2480-507: A window is done by the X Server itself. DRI clients retrieve those buffers to do the rendering into the window by calling operations such as DRI2GetBuffers and DRI2GetBuffersWithFormat available in the DRI2 extension. Internally, DRI2 uses GEM names —a type of global handle provided by the GEM API that allows two processes accessing a DRM device to refer to the same buffer— for passing around "references" to those buffers through

2604-518: A window resize is performed, the X Server is also responsible for allocating new render buffers matching the new window size, and notifying the change to the DRI client(s) rendering into the window using an InvalidateBuffers event, so they would retrieve the GEM names of the new buffers. The DRI2 extension provides other core operations for the DRI clients, such as finding out which DRM device and driver they should use ( DRI2Connect ) or getting authenticated by

SECTION 20

#1732891891444

2728-715: Is 18.2 and available in calendar stable in September. OpenGL 4.6 with spir-V and Vulkan 1.1.80 are in WIP. The soft Driver for virtual machines VIRGL is ready for OpenGL 4.3 and OpenGL ES 3.2. RadeonSI is also ready for OpenGL ES 3.2. ASTC Texture Compression Support and Compatibility Modus Support for OpenGL 4.4 (3.1 in 18.1) are other highlights in RadeonSI for AMD GCN Cards. New Vulkan 1.1 and more features for Intel and AMD are available. See more Details for Vulkan in Mesamatrix. 4th version of 2018

2852-683: Is 18.3 and released as stable Version 18.3.1 in December 2018. Many features in Detail and support of newer hardware are main parts. Full support of OpenGL 4.6 is not ready. 1st Version of 2019 is 19.0 and was now released at March. Full support of OpenGL 4.6 is not ready, but many improvements on this way are in all drivers. 2nd Version of 2019 is 19.1. Transition of TGSI to NIR is here one main Feature on way to OpenGL 4.6 with Spir-V and more OpenCL. RadeonSI runs well in dev-Version with NIR. 3rd Version of 2019

2976-443: Is 19.2. OpenGL 4.6 is Beta ready for new Intel Iris Driver. 4th Version of 2019 is 19.3. OpenGL 4.6 is ready for Intel i965 and optional for new Iris Driver. First Version of 2020 is 20.0. Vulkan 1.2 is ready for AMD RADV and Intel ANV. Intel Iris is default for Intel Broadwell Gen 8+. RadeonSI driver switched to using NIR by default, instead of TGSI. 2nd Version of 2020 is 20.1. Many improvements are ready in many drivers. Zink

3100-489: Is a Linux kernel internal API designed to provide a generic mechanism to share DMA buffers across multiple devices, possibly managed by different types of device drivers. For example, a Video4Linux device and a graphics adapter device could share buffers through DMA-BUF to achieve zero-copy of the data of a video stream produced by the first and consumed by the latter. Any Linux device driver can implement this API as exporter, as user (consumer) or both. This feature

3224-444: Is a new virtual driver for OpenGL over Vulkan. 3rd Version of 2020 is 20.2. OpenGL 3.0 for Zink is one new feature. LLVMpipe will support OpenGL 4.3+ (4.5+ in 20.3). ARM Panfrost is mostly improved with many modules. Shared virtual memory is possible for OpenCL in Nouveau with Pascal and higher. 4th Version of 2020 is 20.3. v3d and v3dv are new drivers for OpenGL and Vulkan 1.0 with Broadcom hardware like Raspberry Pi 4. OpenCL 1.2

3348-407: Is also often called the video or graphics driver . The rise of 3D rendering has shown the limits of this architecture. 3D graphics applications tend to produce large amounts of commands and data, all of which must be dispatched to the X Server for rendering. As the amount of inter-process communication (IPC) between the X client and X Server increased, the 3D rendering performance suffered to

3472-546: Is available at 22.3 with official OpenCL 3.0 Conformance for Intel XE Graphics. Performance is equal and better to AMD ROCm with AMD 6700 XT Card. A main development target of Mesa 23.0 was ray tracing for Vulkan. Microsoft develops the Dozen driver for Vulkan in WSL. Vulkan 1.0+ with 80% 1.1 and 1.2 will be available in Mesa 23.2 after delay to 23.1 (See mesamatrix). RustiCL for AMD hardware

3596-728: Is available in 23.1. VirGL for virtual machines jumps in Mesa 23.2 to OpenGL 4.6. Apple Asahi for Apple Arm Machines jumps from OpenGL 2.1 to 3.1 with 90% features of OpenGL 3.2 and 3.3 and OpenGL ES 2.0 to 3.0. Microsoft Supports in WSL OpenGL 4.6+ in Mesa 24.0 (in Mesa 23.3: 4.3+) with direct 12 translation driver dozen. The Khronos Group officially announced Vulkan API in March 2015, and officially released Vulkan 1.0 on 16 February 2016. Vulkan breaks compatibility with OpenGL and completely abandons its monolithic state machine concept. The developers of Gallium3D called Vulkan to be something along

3720-418: Is better because Present is more efficient than DRI2 in swapping buffers. A number of OpenGL extensions that weren't available with DRI2 are now supported based on new features provided by Present. Present provides two main operations to X clients: update a region of a window using part of or all the contents of a pixmap ( PresentPixmap ) and set the type of presentation events related to a certain window that

3844-487: Is built upon the old KMS API. It uses the same model and objects (CRTCs, encoders, connectors, planes, ...), but with an increasing number of object properties that can be modified. The atomic procedure is based on changing the relevant properties to build the state that we want to test or commit. The properties we want to modify depend on whether we want to do a mode-setting (mostly CRTCs, encoders and connectors properties) or page flipping (usually planes properties). The ioctl

Direct Rendering Infrastructure - Misplaced Pages Continue

3968-544: Is communicate with the X Server to dispatch rendering commands. Those commands are hardware independent, meaning that the X11 protocol provides an API that abstracts the graphics device so the X clients don't need to know or worry about the specifics of the underlying hardware. Any hardware-specific code lives inside the Device Dependent X , the part of the X Server that manages each type of video card or graphics adapter and which

4092-657: Is developed within the Linux kernel , and its source code resides in the /drivers/gpu/drm directory of the Linux source code. The subsystem maintainer is Dave Airlie, with other maintainers taking care of specific drivers. As usual in the Linux kernel development, DRM submaintainers and contributors send their patches with new features and bug fixes to the main DRM maintainer which integrates them into its own Linux repository . The DRM maintainer in turn submits all of these patches that are ready to be mainlined to Linus Torvalds whenever

4216-552: Is done in Benchmark SPECviewperf with improved OpenGL Code. Many Mesa 21.0 features improves performance. New Release 21.0.0 is public since 11 March 2021. Mesa 21.1 is second release of year 2021. OpenGL 4.6+ and OpenGL ES 3.1+ is available for Zink. AMD Driver 600g can change to NIR with more possibilities for old Radeon HD 5000 and 6000 cards. Qualcomm Turnip reaches Vulkan 1.1+ and software emulation Lavapipe Vulkan 1.1+. Google VirtIO GPU Driver Venus with Vulkan 1.2+

4340-478: Is full supported in clover module. Zink support OpenGL 3.3+. LLVMpipe virtual driver support now OpenGL 4.5+ with 4.6 in view. Lavapipe (originally called Vallium ) as Vulkan Tree of LLVMpipe is merged. In Mesa 21.0 d3d12 will be merged with OpenGL 3.0 to 3.3. Microsoft and Collabora develops new emulation d3d12 in WSL2 to Windows 10 with Direct 3D 12. OpenCL 1.2 is also target in d3d12. An acceleration of factor 2 to 5

4464-596: Is hosted by freedesktop.org and was initiated in August 1993 by Brian Paul , who is still active in the project. Mesa was subsequently widely adopted and now contains numerous contributions from various individuals and corporations worldwide, including from the graphics hardware manufacturers of the Khronos Group that administer the OpenGL specification. For Linux, development has also been partially driven by crowdfunding . Mesa

4588-576: Is in now (2017-01-24) Open Source and all tests for Mesa 13 and 17 are now possible without costs. 2nd stable version of 2017, 17.1.0, came out on 10 May 2017 with some interesting improvements. OpenGL 4.2+ for Intel Ivy Bridge and OpenGL 3.3+ for Intel Open SWR Rasterizer are 2 of the highlights. Due to the modularized nature of OpenGL, Mesa can support extensions from newer versions of OpenGL without claiming full support for such versions. For example, in July 2016, Mesa supported OpenGL ES 3.1 but also all OpenGL ES 3.2 extensions except for five, as well as

4712-478: Is known as housing implementations of graphic APIs . Historically the main API that Mesa has implemented is OpenGL , along with other Khronos Group related specifications (like OpenVG , OpenGL ES or recently EGL ). But Mesa can implement other APIs and indeed it did with Glide (deprecated) and Direct3D 9 since July 2013. Mesa is also not specific to Unix-like operating systems: on Windows for example, Mesa provides an OpenGL API over DirectX. Mesa implements

4836-434: Is merged in experimental state with low performance in mesa main tree. Mesa 21.2 is third release of year 2021. Google Virtual Vulkan IO Driver Venus will be official introduced with full Vulkan 1.2+ support (more mesamatrix). ARM Panfrost: OpenGL ES 3.1+ Support is available and panVK is the new Vulkan Driver. Initial support started for ARM Apple M1 with new driver Asahi. 21.2 is available since 4 August 2021. An old plan

4960-729: Is not ready). AMD Vulkan Driver RADV is now fully conformant in Khronos-Test. 1st version of 2018 is 18.0 and available since March 2018 by same scheme in 2017. Full OpenGL 4.6 support is not ready, but many features and improvements were successfully tested in RC3. 10-bit support for Intel i965 in Colors is also a Highlight. New is support for Intel Cannon Lake and AMD Vega with actual Linux Version. AMD Evergreen Chips (RV800 or R900) are near OpenGL 4.5 support. Old AMD R600 or RV700 Chips can only support OpenGL 3.3 with some features of OpenGL 4.x. Freedreno

5084-735: Is the Driver for Adreno Hardware and near OpenGL 3.3 support. 2nd version of 2018 is 18.1 and available since May. Target is Vulkan 1.1.72 in Intel ANV and AMD RADV driver. OpenGL 4.6 with spir-V is also main target. Permanent work is possible completion of Features and Optimization of drivers for older hardware like AMD R600/Evergreen, Nvidia Tesla and before, Fermi, Kepler or Intel Sandybridge, Ivybridge, Haswell or Broadwell. ARM Architecture made also great improvements in Adreno 3xx/4xx/5xx and Broadwell VC4/VC5 for Raspi with main target OpenGL ES. 3rd version of 2018

Direct Rendering Infrastructure - Misplaced Pages Continue

5208-399: Is the Vulkan brother of freedreno for OpenGL. V3dv supports Vulkan 1.0+ since Mesa 20.3. In Version 21.1 Turnip supports Vulkan 1.1+. Direct Rendering Manager The Direct Rendering Manager ( DRM ) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards . DRM exposes an API that user-space programs can use to send commands and data to

5332-496: Is the same for both cases, the difference being the list of properties passed with each one. In the original DRM API, the DRM device /dev/dri/card X is used for both privileged (modesetting, other display control) and non-privileged (rendering, GPGPU compute) operations. For security reasons, opening the associated DRM device file requires special privileges "equivalent to root-privileges". This leads to an architecture where only some reliable user space programs (the X server,

5456-574: Is to be expected that AMD's own proprietary Vulkan driver, which was released in March , and was announced to be released as free and open-source software in the future and be mainlined into Mesa, also abandons Gallium3D. RADV is a free project for AMD and is available since version 13. Conformance with Khronos-Test came in version 17.3. Actual is Full support of Vulkan 1.0 and 1.1 since Mesa 18.1. Nvidia released their proprietary GeForce driver with Vulkan support at launch day and Imagination Technologies (PowerVR), Qualcomm (Adreno) and ARM (Mali) have done

5580-406: Is to split old drivers in a classic tree with many advantages in programming, support, bug fixing for the modern gallium 3D part. One problem here is Intel i965 with support of Popular old hardware to Intel Haswell and before also with Windows 10 support. A new Gallium3D driver Crocus for Intel Gen 4 Graphics to Haswell is here in development to complete here the gallium3D area with possible split in

5704-432: Is within the range of values supported by itself and the attached display screen . This operation is called mode-setting , and it usually requires raw access to the graphics hardware—i.e. the ability to write to certain registers of the video card display controller . A mode-setting operation must be performed before starting to use the framebuffer , and also when the mode is required to change by an application or

5828-560: The 3dfx video cards, as a Linux kernel patch included within the Mesa source code. Later that year, the DRM code was mainlined in Linux kernel 2.3.18 under the /drivers/char/drm/ directory for character devices . During the following years the number of supported video cards grew. When Linux 2.4.0 was released in January 2001 there was already support for Creative Labs GMX 2000, Intel i810, Matrox G200/G400 and ATI Rage 128, in addition to 3dfx Voodoo3 cards, and that list expanded during

5952-455: The Direct Rendering Manager . The new extension was named "DRI2", although it's not a later version but a different extension not even compatible with the original DRI —in fact both have coexisted within the X Server for a long time. In DRI2, instead of a single shared (back) buffer, every DRI client gets its own private back buffer —along with their associated depth and stencil buffers— to render its window content using

6076-549: The Graphics Address Remapping Table (GART). TTM should also handle the portions of the video RAM that are not directly addressable by the CPU and do it with the best possible performance, considering that user-space graphics applications typically work with large amounts of video data. Another important matter was to maintain the consistency between the different memories and caches involved. The main concept of TTM are

6200-419: The Linux kernel , FreeBSD , NetBSD , OpenBSD , and OpenSolaris . The project was started by Jens Owen and Kevin E. Martin from Precision Insight (funded by Silicon Graphics and Red Hat ). It was first made widely available as part of XFree86 4.0 and is now part of the X.Org Server . It is currently maintained by the free software community . Work on DRI2 started at the 2007 X Developers' Summit from

6324-512: The Present extension, to do so. Present is so named because its main task is to "present" buffers on the screen, meaning that it handles the update of the framebuffer using the contents of the rendered buffers delivered by client applications. Screen updates have to be done at the proper time, normally during the VBLANK interval in order to avoid display artifacts such as tearing . Present also handles

SECTION 50

#1732891891444

6448-633: The Unix principle of " everything is a file " to expose the GPUs through the filesystem name space, using device files under the /dev hierarchy. Each GPU detected by DRM is referred to as a DRM device , and a device file /dev/dri/card X (where X is a sequential number) is created to interface with it. User-space programs that want to talk to the GPU must open this file and use ioctl calls to communicate with DRM. Different ioctls correspond to different functions of

6572-448: The X11 protocol . The reason why the X Server is in charge of the buffer allocation of the render buffers of a window is that the GLX extension allows for multiple X clients to do OpenGL rendering cooperatively in the same window. This way, the X Server manages the whole lifecycle of the render buffers along the entire rendering process and knows when it can safely recycle or discard them. When

6696-528: The XFree86 Server —and later the X.Org Server —handled the case when the user switched from the graphical environment to a text virtual console by saving its mode-setting state, and restoring it when the user switched back to X. This process caused an annoying flicker in the transition, and also can fail, leading to a corrupted or unusable output display. The user space mode setting approach also caused other issues: To address these problems,

6820-491: The hardware acceleration . The DRI client then swaps it with a false " front buffer ", which is used by the compositing window manager as one of the sources to compose (build) the final screen back buffer to be swapped at the VBLANK interval with the real front buffer. To handle all these new buffers, the Direct Rendering Manager had to incorporate new functionality, specifically a graphics memory manager . DRI2

6944-453: The mode setting and page flipping operations. This enhanced KMS API is what is called Atomic Display (formerly known as atomic mode-setting and atomic or nuclear pageflip ). The purpose of the atomic mode-setting is to ensure a correct change of mode in complex configurations with multiple restrictions, by avoiding intermediate steps which could lead to an inconsistent or invalid video state; it also avoids risky video states when

7068-501: The "DRI3" extension and the "Present" extension. The main purpose of the DRI3 extension is to implement the mechanism to share direct rendered buffers between DRI clients and the X Server. DRI clients allocate and use GEM buffers objects as rendering targets, while the X Server represents these render buffers using a type of X11 object called "pixmap". DRI3 provides two operations, DRI3PixmapFromBuffer and DRI3BufferFromPixmap , one to create

7192-418: The "buffer objects", regions of video memory that at some point must be addressable by the GPU. When a user-space graphics application wants access to a certain buffer object (usually to fill it with content), TTM may require relocating it to a type of memory addressable by the CPU. Further relocations—or GART mapping operations—could happen when the GPU needs access to a buffer object but it isn't in

7316-399: The 2.4.x series, with drivers for ATI Radeon cards, some SiS video cards and Intel 830M and subsequent integrated GPUs. The split of DRM into two components, DRM core and DRM driver, called DRM core/personality split was done during the second half of 2004, and merged into kernel version 2.6.11. This split allowed multiple DRM drivers for multiple devices to work simultaneously, opening

7440-435: The 3 main manufacturers of GPUs for desktop computers (AMD, NVIDIA and Intel), as well as from a growing number of mobile GPU and System on a chip (SoC) integrators. The quality of each driver varies highly, depending on the degree of cooperation by the manufacturer and other matters. There is also a number of drivers for old, obsolete hardware detailed in the next table for historical purposes. The Direct Rendering Manager

7564-454: The DRM API . A library called libdrm was created to facilitate the interface of user-space programs with the DRM subsystem. This library is merely a wrapper that provides a function written in C for every ioctl of the DRM API, as well as constants, structures and other helper elements. The use of libdrm not only avoids exposing the kernel interface directly to applications, but presents

SECTION 60

#1732891891444

7688-442: The DRM API that either for security purposes or for concurrency issues must be restricted to be used by a single user-space process per device. To implement this restriction, DRM limits such ioctls to be only invoked by the process considered the "master" of a DRM device, usually called DRM-Master . Only one of all processes that have the device node /dev/dri/card X opened will have its file handle marked as master, specifically

7812-430: The DRM API without privileged operations. This design imposes a severe constraint: there must always be a running graphics server (the X Server, a Wayland compositor, ...) acting as DRM-Master of a DRM device so that other user space programs can be granted the use of the device, even in cases not involving any graphics display like GPGPU computations. The "render nodes" concept tries to solve these scenarios by splitting

7936-452: The DRM core to indicate that supports the KMS API. Those drivers that implement Kernel Mode-Setting are often called KMS drivers as a way to differentiate them from the legacy—without KMS—DRM drivers. KMS has been adopted to such an extent that certain drivers which lack 3D acceleration (or for which the hardware vendor doesn't want to expose or implement it) nevertheless implement

8060-465: The DRM user space API into two interfaces – one privileged and one non-privileged – and using separate device files (or "nodes") for each one. For every GPU found, its corresponding DRM driver—if it supports the render nodes feature—creates a device file /dev/dri/renderD X , called the render node , in addition to the primary node /dev/dri/card X . Clients that use a direct rendering model and applications that want to take advantage of

8184-495: The DRM-Master's approval to get such privileges. The procedure consists of: Due to the increasing size of video memory and the growing complexity of graphics APIs such as OpenGL , the strategy of reinitializing the graphics card state at each context switch was too expensive, performance-wise. Also, modern Linux desktops needed an optimal way to share off-screen buffers with the compositing manager . These requirements led to

8308-491: The Direct Rendering Infrastructure involves three main components: In the original DRI architecture, due to the memory size of video cards at that time, there was a single instance of the screen front buffer and back buffer (also of the ancillary depth buffer and stencil buffer ), shared by all the DRI clients and the X Server. All of them rendered directly onto the back buffer, that was swapped with

8432-417: The GEM API beyond the memory-management specific ioctls. Translation Table Maps (TTM) is the name of the generic memory manager for GPUs that was developed before GEM. It was specifically designed to manage the different types of memory that a GPU might access, including dedicated Video RAM (commonly installed in the video card) and system memory accessible through an I/O memory management unit called

8556-444: The GPU and also require management of buffers and free space within that memory. Initially, user-space programs (such as the X Server ) directly managed these resources, but they usually acted as if they were the only ones with access to them. When two or more programs tried to control the same hardware at the same time, and set its resources each one in its own way, most times they ended catastrophically. The Direct Rendering Manager

8680-597: The GPU and memory architecture, and thus driver-specific. GEM was initially developed by Intel engineers to provide a video-memory manager for its i915 driver. The Intel GMA 9xx family are integrated GPUs with a Uniform Memory Architecture (UMA), where the GPU and CPU share the physical memory, and there is not a dedicated VRAM. GEM defines "memory domains" for memory synchronization, and while these memory domains are GPU-independent, they are specifically designed with an UMA memory architecture in mind, making them less suitable for other memory architectures like those with

8804-405: The GPU and perform operations such as configuring the mode setting of the display. DRM was first developed as the kernel-space component of the X Server Direct Rendering Infrastructure , but since then it has been used by other graphic stack alternatives such as Wayland and standalone applications and libraries such as SDL2 and Kodi . User-space programs can use the DRM API to command

8928-430: The GPU to do hardware-accelerated 3D rendering and video decoding , as well as GPGPU computing . The Linux kernel already had an API called fbdev , used to manage the framebuffer of a graphics adapter , but it couldn't be used to handle the needs of modern 3D-accelerated GPU -based video hardware. These devices usually require setting and managing a command queue in their own memory to dispatch commands to

9052-488: The GPU's address space yet. Each of these relocation operations must handle any related data and cache-coherency issues. Another important TTM concept is fences . Fences are essentially a mechanism to manage concurrency between the CPU and the GPU. A fence tracks when a buffer object is no longer used by the GPU, generally to notify any user-space process with access to it. The fact that TTM tried to manage all kind of memory architectures, including those with and without

9176-421: The KMS API without the rest of the DRM API, allowing display servers (like Wayland ) to run with ease. KMS models and manages the output devices as a series of abstract hardware blocks commonly found on the display output pipeline of a display controller . These blocks are: In recent years there has been an ongoing effort to bring atomicity to some regular operations pertaining the KMS API, specifically to

9300-534: The X Server in order to be able to use the rendering and buffer facilities of the DRM device ( DRI2Authenticate ). The presentation of the rendered buffers in the screen is performed using the DRI2CopyRegion and DRI2SwapBuffers requests. DRI2CopyRegion can be used to do a copy between the fake front buffer and the real front buffer, but it doesn't provide any synchronization with the vertical blanking interval, so it can cause tearing . DRI2SwapBuffers , on

9424-486: The X Server. VidMode extension was later superseded by the more generic XRandR extension. However, this was not the only code doing mode-setting in a Linux system. During the system booting process, the Linux kernel must set a minimal text mode for the virtual console (based on the standard modes defined by VESA BIOS extensions). Also the Linux kernel framebuffer driver contained mode-setting code to configure framebuffer devices. To avoid mode-setting conflicts,

9548-644: The X.Org Server 1.15 release from December 2013. The first and only version of the DRI3 protocol (1.0) was released in November 2013. Mesa 3D Mesa , also called Mesa3D and The Mesa 3D Graphics Library , is an open source implementation of OpenGL , Vulkan , and other graphics API specifications. Mesa translates these specifications to vendor-specific graphics hardware drivers. Its most important users are two graphics drivers mostly developed and funded by Intel and AMD for their respective hardware (AMD promotes their Mesa drivers Radeon and RadeonSI over

9672-547: The additional ioctls. The DRM core exports several interfaces to user-space applications, generally intended to be used through corresponding libdrm wrapper functions. In addition, drivers export device-specific interfaces for use by user-space drivers and device-aware applications through ioctls and sysfs files. External interfaces include: memory mapping, context management, DMA operations, AGP management, vblank control, fence management, memory management, and output management. There are several operations (ioctls) in

9796-400: The allocated memory in coming operations. GEM API also provides operations to populate the buffer and to release it when it is not needed anymore. Memory from unreleased GEM handles gets recovered when the user-space process closes the DRM device file descriptor —intentionally or because it terminates. GEM also allows two or more user-space processes using the same DRM device (hence

9920-477: The approach taken by TTM was more suitable for discrete video cards with dedicated video memory and IOMMUs, so they decided to use TTM internally, while exposing their buffer objects as GEM objects and thus supporting the GEM API. Examples of current drivers using TTM as an internal memory manager but providing a GEM API are the radeon driver for AMD video cards and the nouveau driver for NVIDIA video cards. The DMA Buffer Sharing API (often abbreviated as DMA-BUF)

10044-503: The basis on which to render only the damaged parts of a window as another performance optimization. The DRI3 extension no longer needs to be modified to support new particular buffer formats, since they are now handled directly between the DRI client driver and the DRM kernel driver. The use of file descriptors, on the other hand, allows the kernel to perform a safe cleanup of any unused GEM buffer object —one with no reference to it. Technically, DRI3 consists of two different extensions,

10168-412: The classical X architecture. The Direct Rendering Infrastructure was initially developed to allow any X client to perform 3D rendering using this "direct rendering" approach. Nothing prevents DRI from being used to implement accelerated 2D direct rendering within an X client. Simply no one has had the need to do so because the 2D indirect rendering performance was good enough. The basic architecture of

10292-408: The client side breaks GLX assumptions in the sense that it's no longer possible for multiple GLX applications to render cooperatively in the same window. On the plus side, the fact that the DRI client is in charge of its own buffers throughout their lifetime brings many advantages. For example, it is easy for the DRI3 client to ensure that the size of the render buffers always match the current size of

10416-498: The client wants to be notified about ( PresentSelectInput ). There are three presentation events about which a window can notify an X client: when an ongoing presentation operation —normally from a call to PresentPixmap — has been completed ( PresentCompleteNotify ), when a pixmap used by a PresentPixmap operation is ready to be reused ( PresentIdleNotify ) and when the window configuration —mostly window size— changes ( PresentConfigureNotify ). Whether

10540-527: The community driver RADV. OpenGL ES 3.2 is possible with Intel Skylake (Gen9). 1st stable version of 2017 is 17.0 (new year Counting). Ready features are certified OpenGL 4.5, OpenGL 4.5 for Intel Haswell, OpenGL 4.3 for Nvidia Maxwell and Pascal (GM107+). Huge performance gain was measured with Maxwell 1 (GeForce GTX 750 Ti and more with GM1xx). Maxwell-2-Cards (GeForce GTX 980 and more with GM2xx) are underclocked without Nvidia information. The Khronos CTS test suite for OpenGL 4.4, 4.5 and OpenGL ES 3.0+

10664-424: The computing facilities of a GPU, can do it without requiring additional privileges by simply opening any existing render node and dispatching GPU operations using the limited subset of the DRM API supported by those nodes—provided they have file system permissions to open the device file. Display servers, compositors and any other program that requires the modeset API or any other privileged operation must open

10788-406: The corresponding device node during its startup, and keeps these privileges for the entire graphical session until it finishes or dies. For the remaining user-space processes there is another way to gain the privilege to invoke some restricted operations on the DRM device called DRM-Auth . It is basically a method of authentication against the DRM device, in order to prove to it that the process has

10912-517: The deprecated AMD Catalyst , and Intel has only supported the Mesa driver). Proprietary graphics drivers (e.g., Nvidia GeForce driver and Catalyst) replace all of Mesa, providing their own implementation of a graphics API. An open-source effort to write a Mesa Nvidia driver called Nouveau is developed mostly by the community. Besides 3D applications such as games, modern display servers ( X.org's Glamor or Wayland 's Weston ) use OpenGL/ EGL ; therefore all graphics typically go through Mesa. Mesa

11036-468: The development of new methods to manage graphics buffers inside the kernel. The Graphics Execution Manager (GEM) emerged as one of these methods. GEM provides an API with explicit memory management primitives. Through GEM, a user-space program can create, handle and destroy memory objects living in the GPU video memory. These objects, called "GEM objects", are persistent from the user-space program's perspective and don't need to be reloaded every time

11160-546: The first calling the SET_MASTER ioctl. Any attempt to use one of these restricted ioctls without being the DRM-Master will return an error. A process can also give up its master role—and let another process acquire it—by calling the DROP_MASTER ioctl. The X Server —or any other display server —is commonly the process that acquires the DRM-Master status in every DRM device it manages, usually when it opens

11284-418: The flickering issues while changing between console and X, and also between different instances of X (fast user switching). Since it is available in the kernel, it can also be used at the beginning of the boot process, saving flickering due to mode changes in these early stages. The fact that KMS is part of the kernel allows it to use resources only available at kernel space such as interrupts . For example,

11408-456: The front buffer at vertical blanking interval time. In order to render to the back buffer, a DRI process should ensure that the rendering was clipped to the area reserved for its window . The synchronization with the X Server was done through signals and a shared memory buffer called the SAREA. The access to the DRM device was exclusive, so any DRI client had to lock it at the beginning of

11532-477: The graphics memory such as textures were lost for upcoming operations, causing a significant impact on graphics performance. Nowadays DRI1 is considered completely obsolete and must not be used. Due to the increasing popularity of compositing window managers like Compiz , the Direct Rendering Infrastructure had to be redesigned so that X clients could also support redirection to "offscreen pixmaps" while doing direct rendering. Regular X clients already respected

11656-457: The hardware-dependent part of the API, specific to the type of GPU it supports; it should provide the implementation of the remaining ioctls not covered by DRM core, but it may also extend the API, offering additional ioctls with extra functionality only available on such hardware. When a specific DRM driver provides an enhanced API, user-space libdrm is also extended by an extra library libdrm- driver that can be used by user space to interface with

11780-402: The isolation that operating systems should provide between programs and hardware, raising both stability and security concerns, but also could leave the graphics hardware in an inconsistent state if two or more user space programs try to do the mode-setting at the same time. To avoid these conflicts, the X Server became in practice the only user space program that performed mode-setting operations;

11904-454: The lines of Gallium3D 2.0 – Gallium3D separates the code that implements the OpenGL state machine from the code that is specific to the hardware. Version 1.3 is immediately available with Mesa 22.0. Hardware with support of OpenGL ES 3.1 should run at Vulkan Level 1.3 and before. As Gallium3D ingests TGSI, Vulkan ingests SPIR-V ( Standard Portable Intermediate Representation version "V" as in "Vulkan"). Intel released their implementation of

12028-416: The mode recovery after a suspend/resume process simplifies a lot by being managed by the kernel itself, and incidentally improves security (no more user space tools requiring root permissions). The kernel also allows the hotplug of new display devices easily, solving a longstanding problem. Mode-setting is also closely related to memory management—since framebuffers are basically memory buffers—so

12152-429: The mode-setting code was moved to a single place inside the kernel, specifically to the existing DRM module. Then, every process—including the X Server—should be able to command the kernel to perform mode-setting operations, and the kernel would ensure that concurrent operations don't result in an inconsistent state. The new kernel API and code added to the DRM module to perform these mode-setting operations

12276-420: The next time of year 2021. Crocus is optional available in 21.2. Amber branch is for old drivers without Gallium 3D Functions like Radeon R200, intel i915 and 965 with actual version 21.3.9. In Version 22.0 Classic drivers are retired. Vulkan 1.3 is available for Intel Anvil and AMD RADV. Microsoft introduces new driver „Dozen“ for WSL 2 in early development stage as Vulkan over d3d12 in Mesa 22.1. RustiCL

12400-421: The other hand allows to update multiple planes on the same output (for instance the primary plane, the cursor plane and maybe some overlays or secondary planes) all synchronized within the same VBLANK interval, ensuring a proper display without tearing. This requirement is especially relevant to mobile and embedded display controllers, that tend to use multiple planes/overlays to save power. The new atomic API

12524-487: The other hand, performs a VBLANK-synchronized swap between back and front buffer, if it's supported and both buffers have the same size, or a copy ( blit ) otherwise. Although DRI2 was a significant improvement over the original DRI, the new extension also introduced some new issues. In 2013, a third iteration of the Direct Rendering Infrastructure known as DRI3 was developed in order to fix those issues. The main differences of DRI3 compared to DRI2 are: Buffer allocation on

12648-450: The point that X driver developers concluded that in order to take advantage of 3D hardware capabilities of the latest graphics cards a new IPC-less architecture was required. X clients should have direct access to graphics hardware rather than relying on another process to do so, saving all the IPC overhead. This approach is called "direct rendering" as opposed to the "indirect rendering" provided by

12772-415: The program regains control of the GPU. When a user-space program needs a chunk of video memory (to store a framebuffer , texture or any other data required by the GPU ), it requests the allocation to the DRM driver using the GEM API. The DRM driver keeps track of the used video memory and is able to comply with the request if there is free memory available, returning a "handle" to user space to further refer

12896-445: The redirection to a separate pixmap provided by the X Server as a render target —the so-called offscreen pixmap—, but DRI clients continued to do the rendering directly into the shared backbuffer, effectively bypassing the compositing window manager. The ultimate solution was to change the way DRI handled the render buffers, which led to a completely different DRI extension with a new set of operations, and also major changes in

13020-484: The remainder user space programs relied on the X Server to set the appropriate mode and to handle any other operation involving mode-setting. Initially the mode-setting was performed exclusively during the X Server startup process, but later the X Server gained the ability to do it while running. The XFree86-VidModeExtension extension was introduced in XFree86 3.1.2 to let any X client request modeline (resolution) changes to

13144-541: The same DRM device could try to guess the GEM name of a buffer shared by two other processes, simply by probing 32-bit integers. Once a GEM name is found, its contents can be accessed and modified, violating the confidentiality and integrity of the information of the buffer. This drawback was overcome later by the introduction of DMA-BUF support into DRM, as DMA-BUF represents buffers in userspace as file descriptors, which may be shared securely . Another important task for any video-memory management system besides managing

13268-405: The same DRM driver) to share a GEM object. GEM handles are local 32-bit integers unique to a process but repeatable in other processes, therefore not suitable for sharing. What is needed is a global namespace, and GEM provides one through the use of global handles called GEM names . A GEM name refers to one, and only one, GEM object created within the same DRM device by the same DRM driver, by using

13392-682: The same or at least announced proprietary Vulkan drivers for Android and other operating systems. But when and whether additional free and open-source Vulkan implementations for these GPUs will show up, remains to be seen. Mesa Software Driver VIRGL starts Vulkan Development in 2018 with GSOC projects for support of Virtual machines. Lavapipe is a CPU-based Software Vulkan driver and the brother of LLVMpipe. Mesa Version 21.1 supports Vulkan 1.1+. Google introduces Venus Vulkan Driver for virtual machines in Mesa 21.1 with full support for Vulkan 1.2+. Qualcomm Turnip and Broadcom v3dv are new drivers for Qualcomm Adreno and Broadcom Raspberry 4 Hardware. Turnip

13516-443: The shared buffer. Unlike DRI2, the initial DRI3Open operation —the first every DRI client must request to know which DRM device to use— returns an already open file descriptor to the device node instead of the device node filename, with any required authentication procedure already performed in advance by the X Server. DRI3 provides no mechanism to show the rendered buffers on the screen, but relies on another extension,

13640-417: The standard primary node that grants access to the full DRM API and use it as usual. Render nodes explicitly disallow the GEM flink operation to prevent buffer sharing using insecure GEM global names; only PRIME (DMA-BUF) file descriptors can be used to share buffers with another client, including the graphics server. The Linux DRM subsystem includes free and open-source drivers to support hardware from

13764-592: The supported extensions and versions. Mesa maintains a support matrix with the status of the current OpenGL conformance visualized at mesamatrix .net . Mesa 10 complies with OpenGL 3.3 for Intel, AMD/ATI, and Nvidia GPU hardware. Mesa 11 was announced with some drivers being OpenGL 4.1 compliant. Mesa 12 contains OpenGL 4.2 and 4.3 and Intel Vulkan 1.0 support. Mesa 13 brought Intel support for OpenGL 4.4 and 4.5 (all Features supported for Intel Gen 8+, Radeon GCN, Nvidia (Fermi, Kepler), but no Khronos-Test for 4.5-Label) and experimental AMD Vulkan 1.0 support through

13888-526: The synchronization of screen updates to the VBLANK interval. It also keeps the X client informed about the instant each buffer is really shown on the screen using events, so the client can synchronize its rendering process with the current screen refresh rate. Present accepts any X pixmap as the source for a screen update. Since pixmaps are standard X objects, Present can be used not only by DRI3 clients performing direct rendering, but also by any X client rendering on

14012-580: The user. In early days, the user space programs that wanted to use the graphical framebuffer were also responsible for providing the mode-setting operations, and therefore they needed to run with privileged access to the video hardware. In Unix-type operating systems, the X Server was the most prominent example, and its mode-setting implementation lived in the DDX driver for each specific type of video card. This approach, later referred to as User space Mode-Setting or UMS, poses several issues. It not only breaks

14136-419: The usual advantages of reusing and sharing code between programs. DRM consists of two parts: a generic "DRM core" and a specific one ("DRM driver") for each type of supported hardware. DRM core provides the basic framework where different DRM drivers can register and also provides to user space a minimal set of ioctls with common, hardware-independent functionality. A DRM driver, on the other hand, implements

14260-483: The video-memory space is handling the memory synchronization between the GPU and the CPU. Current memory architectures are very complex and usually involve various levels of caches for the system memory and sometimes for the video memory too. Therefore, video-memory managers should also handle the cache coherence to ensure the data shared between CPU and GPU is consistent. This means that often video-memory management internals are highly dependent on hardware details of

14384-486: The way to multi-GPU support. The idea of putting all the video mode setting code in one place inside the kernel had been acknowledged for years, but the graphics card manufacturers had argued that the only way to do the mode-setting was to use the routines provided by themselves and contained in the Video BIOS of each graphics card. Such code had to be executed using x86 real mode , which prevented it from being invoked by

14508-606: The whole kernel DRM subsystem. The trend to include two GPUs in a computer—a discrete GPU and an integrated one—led to new problems such as GPU switching that also needed to be solved at the DRM layer. In order to match the Nvidia Optimus technology, DRM was provided with GPU offloading abilities, called PRIME. The Direct Rendering Manager resides in kernel space , so user-space programs must use kernel system calls to request its services. However, DRM doesn't define its own customized system calls. Instead, it follows

14632-444: The window, and thereby eliminate the artifacts due to the lack of synchronization of buffer sizes between client and server that plagued window resizing in DRI2. A better performance is also achieved because now DRI3 clients save the extra round trip waiting for the X Server to send the render buffers. DRI3 clients, and especially compositor window managers, can take advantage of keeping older buffers of previous frames and reusing them as

14756-428: The years to cover more functionality previously handled by user-space programs, such as framebuffer managing and mode setting , memory-sharing objects and memory synchronization. Some of these expansions were given specific names, such as Graphics Execution Manager (GEM) or kernel mode-setting (KMS), and the terminology prevails when the functionality they provide is specifically alluded. But they are really parts of

14880-422: Was announced in April 2009. Since then there have been several revisions, the most recent being version 2.8 from July 2012. Due to several limitations of DRI2, a new extension called DRI-Next was proposed by Keith Packard and Emma Anholt at the X.Org Developer's Conference 2012. The extension was proposed again as DRI3000 at Linux.conf.au 2013. DRI3 and Present extensions were developed during 2013 and merged into

15004-430: Was called Kernel Mode-Setting (KMS). Kernel Mode-Setting provides several benefits. The most immediate is of course the removal of duplicate mode-setting code, from both the kernel (Linux console, fbdev) and user space (X Server DDX drivers). KMS also makes it easier to write alternative graphics systems, which now don't need to implement their own mode-setting code. By providing centralized mode management, KMS solves

15128-407: Was created to allow multiple programs to use video hardware resources cooperatively. The DRM gets exclusive access to the GPU and is responsible for initializing and maintaining the command queue, memory, and any other hardware resource. Programs wishing to use the GPU send requests to DRM, which acts as an arbitrator and takes care to avoid possible conflicts. The scope of DRM has been expanded over

15252-407: Was exploited for the first time in DRM to implement PRIME, a solution for GPU offloading that uses DMA-BUF to share the resulting framebuffers between the DRM drivers of the discrete and the integrated GPU. An important feature of DMA-BUF is that a shared buffer is presented to user space as a file descriptor . For the development of PRIME two new ioctls were added to the DRM API, one to convert

15376-433: Was initially developed using the experimental TTM memory manager, but it was later rewritten to use GEM after it was chosen as the definitive DRM memory manager. The new DRI2 internal buffer management model also solved two major performance bottlenecks present in the original DRI implementation: In DRI2, the allocation of the private offscreen buffers (back buffer, fake front buffer, depth buffer, stencil buffer, ...) for

#443556