Graphics Execution Manager

From Wikipedia, the free encyclopedia
Jump to: navigation, search
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] Drivers for ATI 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[edit]

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[edit]

The role of KMS (Kernel mode-setting), Linux example

The Linux graphic stack
Illustrates the Linux graphics stack current as of 2013-08-24
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[edit]

References[edit]

  1. ^ a b Michael Larabel (June 12, 2008). "Intel's GEM Merging To Master". Phoronix. 
  2. ^ a b 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[edit]