Graphics Execution Manager

Rendering calculations are outsourced over OpenGL to the GPU to be done in real-time. DRI-components like GEM regulate access and do book-keeping. It all seems superfluous when only a fullscreen 3D game is running, but hardware access is a fundamental kernel task.

The Graphics Execution Manager (GEM) is a computer software system developed by Intel to do memory management for device drivers for graphics chipsets. GEM is part of the Direct Rendering Manager.

GEM manages graphics memory (which means dealing with Non-Uniform Memory Access (NUMA) on modern graphics chipsets) and controls the execution context for graphics-related code. They allow multiple applications to share graphics device resources without the need to store and restore the entire graphics card state between changes. GEM ensures conflict-free sharing of data between applications by managing the memory synchronization. It uses many existing kernel subsystems for its operations and hence has a very modest code size.

GEM is included in the Linux kernel from version 2.6.28 for use by drivers for Intel graphics hardware.[1] Graphics device drivers for AMD's Radeon and VIA S3 chipsets now use a "GEM-ified TTM manager", which provides the same interface as GEM but uses TTM internally.[2][3] GEM is also designed to be compatible with "*BSD" kernels.

GEM's API is documented in the original announcement of GEM.[4]

History

GEM was developed by Intel, starting in May 2008, as a minimalist, easy-to-use alternative to the Translation Table Maps memory manager developed by Tungsten Graphics.[1][5]

However, GEM caused problems for non-Intel developers and collided with current X.Org Server development (notably DRI2 and new EXA acceleration architecture), leading some developers to use a "GEM-ified TTM manager".[2]

DRI2 introduced a technique called Global GEM Handlers, this has some serious security implications and is going to be replaced in the successor to DRI2 with a passing of DMA_BUF file descriptors that point to GEM objects instead.[6]

Software architecture

The role of KMS (Kernel mode-setting), Linux example
The Linux graphic stack
Illustrates the Linux graphics stack current as of 2013-08-24
Scheme: Humane-machine_interaction
evdev is to the INPUT what the GEM is to the OUTPUT. Many applications require the entire loop (INPUT-PROCESSING-OUPUT to have minimal latency
The place of certain Linux kernel modules
evdev is the Linux kernel module that receives data from various Input devices such as Keyboard, Mouse, Touch-Pad, etc. The data is passed to the Display server (e.g. the X.Org Server or some Wayland compositor only to be passed further to the wayland respectively X client. Some applications require a minimal latency

See also

References

  1. ↑ 1.0 1.1 Michael Larabel (June 12, 2008). "Intel's GEM Merging To Master". Phoronix.
  2. ↑ 2.0 2.1 Michael Larabel (August 26, 2008). "A GEM-ified TTM Manager For Radeon". Phoronix.
  3. ↑ Michael Larabel (June 10, 2009). "TTM Memory Manager Gets Ready For Release". Phoronix.
  4. ↑ Keith Packard (May 27, 2008). "GEM - the Graphics Execution Manager". LWN.net.
  5. ↑ Michael Larabel (May 14, 2008). "Intel's Graphics Execution Manager". Phoronix.
  6. ↑ Keith Packard. "Future directions for the X Window System". linux.conf.au.

External links