Lines Matching full:gem

12 (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory
20 GEM started as an Intel-sponsored project in reaction to TTM's
22 providing a solution to every graphics memory-related problems, GEM
24 share it. GEM has simpler initialization and execution requirements than
79 The Graphics Execution Manager (GEM)
82 The GEM design approach has resulted in a memory manager that doesn't
84 userspace or kernel API. GEM exposes a set of standard memory-related
89 The GEM userspace API is described in the `GEM - the Graphics Execution
91 slightly outdated, the document provides a good overview of the GEM API
93 as part of the common GEM API, are currently implemented using
96 GEM is data-agnostic. It manages abstract buffer objects without knowing
99 primitives, are thus outside of the scope of GEM and must be implemented
102 On a fundamental level, GEM involves several operations:
116 GEM Initialization
119 Drivers that use GEM must set the DRIVER_GEM bit in the struct
121 field. The DRM core will then automatically initialize the GEM core
127 command ring buffer following core GEM initialization if required by the
131 typically not managed by GEM, and must be initialized separately into
134 GEM Objects Creation
137 GEM splits creation of GEM objects and allocation of the memory that
140 GEM objects are represented by an instance of struct :c:type:`struct
142 extend GEM objects with private information and thus create a
143 driver-specific GEM object structure type that embeds an instance of
146 To create a GEM object, a driver allocates memory for an instance of its
147 specific GEM object type and initializes the embedded struct
150 to the DRM device, a pointer to the GEM object and the buffer object
153 GEM uses shmem to allocate anonymous pageable memory.
162 Note that they can decide to allocate pages when initializing the GEM
169 often the case in embedded devices. Drivers can create GEM objects with
170 no shmfs backing (called private GEM objects) by initializing them with a call
172 private GEM objects must be managed by drivers.
174 GEM Objects Lifetime
177 All GEM objects are reference-counted by the GEM core. References can be
181 When the last reference to a GEM object is released the GEM core calls
183 operation. That operation is mandatory for GEM-enabled drivers and must
184 free the GEM object and all associated resources.
187 responsible for freeing all GEM object resources. This includes the
188 resources created by the GEM core, which need to be released with
191 GEM Objects Naming
194 Communication between userspace and the kernel refers to GEM objects
199 GEM handles are local to a DRM file. Applications get a handle to a GEM
201 to the GEM object in other standard or driver-specific ioctls. Closing a
202 DRM file handle frees all its GEM handles and dereferences the
203 associated GEM objects.
205 To create a handle for a GEM object drivers call drm_gem_handle_create(). The
206 function takes a pointer to the DRM file and the GEM object and returns a
208 with a call to drm_gem_handle_delete(). Finally the GEM object associated with a
211 Handles don't take ownership of GEM objects, they only take a reference
213 avoid leaking GEM objects, drivers must make sure they drop the
216 handle. For example, in the particular case of combined GEM object and
218 drivers must drop the initial reference to the GEM object before
221 GEM names are similar in purpose to handles but are not local to DRM
222 files. They can be passed between processes to reference a GEM object
229 GEM also supports buffer sharing with dma-buf file descriptors through
230 PRIME. GEM-based drivers must use the provided helpers functions to
233 global GEM names it is the preferred buffer sharing mechanism. Sharing
234 buffers through GEM names is only supported for legacy userspace.
238 GEM Objects Mapping
241 Because mapping operations are fairly heavyweight GEM favours
247 The mmap system call can't be used directly to map GEM objects, as they
249 co-exist to map GEM objects to userspace. The first method uses a
252 dubious, seems to be discouraged for new GEM-enabled drivers, and will
257 offset); DRM identifies the GEM object to be mapped by a fake offset
258 passed through the mmap offset argument. Prior to being mapped, a GEM
266 The GEM core provides a helper method drm_gem_mmap() to
268 operation handler. It will look up the GEM object based on the offset
289 The open and close operations must update the GEM object reference
296 decide to allocate memory for the GEM object at the time the object is
299 Drivers that want to map the GEM object upfront instead of handling page
302 For platforms without MMU the GEM core provides a helper method
332 Perhaps the most important GEM function for GPU devices is providing a
335 objects, and then submit them to GEM. At that point, GEM takes care to
342 the GTT; otherwise, GEM will reject them and no rendering will occur.
349 GEM Function Reference
358 GEM DMA Helper Functions Reference
370 GEM SHMEM Helper Function Reference
382 GEM VRAM Helper Functions Reference
394 GEM TTM Helper Functions Reference