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
82 The Graphics Execution Manager (GEM)
85 The GEM design approach has resulted in a memory manager that doesn't
87 userspace or kernel API. GEM exposes a set of standard memory-related
92 The GEM userspace API is described in the `GEM - the Graphics Execution
94 slightly outdated, the document provides a good overview of the GEM API
96 as part of the common GEM API, are currently implemented using
99 GEM is data-agnostic. It manages abstract buffer objects without knowing
102 primitives, are thus outside of the scope of GEM and must be implemented
105 On a fundamental level, GEM involves several operations:
119 GEM Initialization
122 Drivers that use GEM must set the DRIVER_GEM bit in the struct
124 field. The DRM core will then automatically initialize the GEM core
130 command ring buffer following core GEM initialization if required by the
134 typically not managed by GEM, and must be initialized separately into
137 GEM Objects Creation
140 GEM splits creation of GEM objects and allocation of the memory that
143 GEM objects are represented by an instance of struct :c:type:`struct
145 extend GEM objects with private information and thus create a
146 driver-specific GEM object structure type that embeds an instance of
149 To create a GEM object, a driver allocates memory for an instance of its
150 specific GEM object type and initializes the embedded struct
153 to the DRM device, a pointer to the GEM object and the buffer object
156 GEM uses shmem to allocate anonymous pageable memory.
165 Note that they can decide to allocate pages when initializing the GEM
172 often the case in embedded devices. Drivers can create GEM objects with
173 no shmfs backing (called private GEM objects) by initializing them with a call
175 private GEM objects must be managed by drivers.
177 GEM Objects Lifetime
180 All GEM objects are reference-counted by the GEM core. References can be
184 When the last reference to a GEM object is released the GEM core calls
186 operation. That operation is mandatory for GEM-enabled drivers and must
187 free the GEM object and all associated resources.
190 responsible for freeing all GEM object resources. This includes the
191 resources created by the GEM core, which need to be released with
194 GEM Objects Naming
197 Communication between userspace and the kernel refers to GEM objects
202 GEM handles are local to a DRM file. Applications get a handle to a GEM
204 to the GEM object in other standard or driver-specific ioctls. Closing a
205 DRM file handle frees all its GEM handles and dereferences the
206 associated GEM objects.
208 To create a handle for a GEM object drivers call drm_gem_handle_create(). The
209 function takes a pointer to the DRM file and the GEM object and returns a
211 with a call to drm_gem_handle_delete(). Finally the GEM object associated with a
214 Handles don't take ownership of GEM objects, they only take a reference
216 avoid leaking GEM objects, drivers must make sure they drop the
219 handle. For example, in the particular case of combined GEM object and
221 drivers must drop the initial reference to the GEM object before
224 GEM names are similar in purpose to handles but are not local to DRM
225 files. They can be passed between processes to reference a GEM object
232 GEM also supports buffer sharing with dma-buf file descriptors through
233 PRIME. GEM-based drivers must use the provided helpers functions to
236 global GEM names it is the preferred buffer sharing mechanism. Sharing
237 buffers through GEM names is only supported for legacy userspace.
241 GEM Objects Mapping
244 Because mapping operations are fairly heavyweight GEM favours
250 The mmap system call can't be used directly to map GEM objects, as they
252 co-exist to map GEM objects to userspace. The first method uses a
255 dubious, seems to be discouraged for new GEM-enabled drivers, and will
260 offset); DRM identifies the GEM object to be mapped by a fake offset
261 passed through the mmap offset argument. Prior to being mapped, a GEM
269 The GEM core provides a helper method drm_gem_mmap() to
271 operation handler. It will look up the GEM object based on the offset
292 The open and close operations must update the GEM object reference
299 decide to allocate memory for the GEM object at the time the object is
302 Drivers that want to map the GEM object upfront instead of handling page
305 For platforms without MMU the GEM core provides a helper method
335 Perhaps the most important GEM function for GPU devices is providing a
338 objects, and then submit them to GEM. At that point, GEM takes care to
345 the GTT; otherwise, GEM will reject them and no rendering will occur.
352 GEM Function Reference
361 GEM CMA Helper Functions Reference
373 GEM SHMEM Helper Function Reference
385 GEM VRAM Helper Functions Reference
397 GEM TTM Helper Functions Reference