libdrm: Changes to 'debian-experimental'
Makefile.in | 674 -
aclocal.m4 | 7532 --------------
bsd-core/i915_suspend.c | 1
bsd-core/radeon_microcode.h | 1
config.guess | 1526 --
config.sub | 1658 ---
configure |22485 -------------------------------------------
debian/changelog | 7
debian/control | 2
debian/libdrm2.shlibs | 2
debian/libdrm2.symbols | 137
debian/rules | 46
debian/xsfbs/xsfbs.mk | 293
debian/xsfbs/xsfbs.sh | 931 +
depcomp | 589 -
install-sh | 519
libdrm/Makefile.in | 540 -
libdrm/config.h.in | 61
linux-core/drm-gem.txt | 805 -
linux-core/drm_gem.c | 444
linux-core/i915_gem.c | 2502 ----
linux-core/i915_gem_debug.c | 202
linux-core/i915_gem_proc.c | 293
linux-core/i915_gem_tiling.c | 309
linux-core/i915_opregion.c | 389
linux-core/i915_suspend.c | 1
linux-core/nv50_grctx.h | 1
ltmain.sh | 6964 -------------
missing | 367
shared-core/Makefile.in | 438
tests/Makefile.in | 611 -
31 files changed, 1399 insertions(+), 48931 deletions(-)
New commits:
commit 3d9e1c4f852673afa5ad372cc580226ded539a8e
Author: Timo Aaltonen <tjaalton@cc.hut.fi>
Date: Tue Nov 25 12:31:28 2008 +0200
Use dh_makeshlibs properly
Add a debian/libdrm2.symbols file and '-c4' parameter to dh_makeshlibs
to fail if new symbols are added. Don't use Debian versions for now.
diff --git a/debian/changelog b/debian/changelog
index fe90602..40068af 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,9 +2,12 @@ libdrm (2.4.1-1) UNRELEASED; urgency=low
* New upstream release.
* Bump the shlibs to 2.4.1.
- * Run autoreconf at build time, build-depend on automake and libtool.
+ * debian/rules:
+ -Run autoreconf at build time, build-depend on automake and libtool.
+ -Add a debian/libdrm2.symbols file and '-c4' parameter to dh_makeshlibs
+ to fail if new symbols are added. Don't use Debian versions for now.
- -- Timo Aaltonen <tepsipakki@ubuntu.com> Tue, 25 Nov 2008 10:52:54 +0200
+ -- Timo Aaltonen <tepsipakki@ubuntu.com> Tue, 25 Nov 2008 12:28:20 +0200
libdrm (2.3.1-2) unstable; urgency=high
diff --git a/debian/libdrm2.symbols b/debian/libdrm2.symbols
new file mode 100644
index 0000000..b5e3368
--- /dev/null
+++ b/debian/libdrm2.symbols
@@ -0,0 +1,137 @@
+libdrm.so.2 libdrm2 #MINVER#
+ drmAddBufs@Base 2.3.1
+ drmAddContextPrivateMapping@Base 2.3.1
+ drmAddContextTag@Base 2.3.1
+ drmAddMap@Base 2.3.1
+ drmAgpAcquire@Base 2.3.1
+ drmAgpAlloc@Base 2.3.1
+ drmAgpBase@Base 2.3.1
+ drmAgpBind@Base 2.3.1
+ drmAgpDeviceId@Base 2.3.1
+ drmAgpEnable@Base 2.3.1
+ drmAgpFree@Base 2.3.1
+ drmAgpGetMode@Base 2.3.1
+ drmAgpMemoryAvail@Base 2.3.1
+ drmAgpMemoryUsed@Base 2.3.1
+ drmAgpRelease@Base 2.3.1
+ drmAgpSize@Base 2.3.1
+ drmAgpUnbind@Base 2.3.1
+ drmAgpVendorId@Base 2.3.1
+ drmAgpVersionMajor@Base 2.3.1
+ drmAgpVersionMinor@Base 2.3.1
+ drmAuthMagic@Base 2.3.1
+ drmAvailable@Base 2.3.1
+ drmClose@Base 2.3.1
+ drmCloseOnce@Base 2.3.1
+ drmCommandNone@Base 2.3.1
+ drmCommandRead@Base 2.3.1
+ drmCommandWrite@Base 2.3.1
+ drmCommandWriteRead@Base 2.3.1
+ drmCreateContext@Base 2.3.1
+ drmCreateDrawable@Base 2.3.1
+ drmCtlInstHandler@Base 2.3.1
+ drmCtlUninstHandler@Base 2.3.1
+ drmDMA@Base 2.3.1
+ drmDelContextTag@Base 2.3.1
+ drmDestroyContext@Base 2.3.1
+ drmDestroyDrawable@Base 2.3.1
+ drmError@Base 2.3.1
+ drmFinish@Base 2.3.1
+ drmFree@Base 2.3.1
+ drmFreeBufs@Base 2.3.1
+ drmFreeBusid@Base 2.3.1
+ drmFreeReservedContextList@Base 2.3.1
+ drmFreeVersion@Base 2.3.1
+ drmGetBufInfo@Base 2.3.1
+ drmGetBusid@Base 2.3.1
+ drmGetClient@Base 2.3.1
+ drmGetContextFlags@Base 2.3.1
+ drmGetContextPrivateMapping@Base 2.3.1
+ drmGetContextTag@Base 2.3.1
+ drmGetEntry@Base 2.3.1
+ drmGetHashTable@Base 2.3.1
+ drmGetInterruptFromBusID@Base 2.3.1
+ drmGetLibVersion@Base 2.3.1
+ drmGetLock@Base 2.3.1
+ drmGetMagic@Base 2.3.1
+ drmGetMap@Base 2.3.1
+ drmGetReservedContextList@Base 2.3.1
+ drmGetStats@Base 2.3.1
+ drmGetVersion@Base 2.3.1
+ drmHashCreate@Base 2.3.1
+ drmHashDelete@Base 2.3.1
+ drmHashDestroy@Base 2.3.1
+ drmHashFirst@Base 2.3.1
+ drmHashInsert@Base 2.3.1
+ drmHashLookup@Base 2.3.1
+ drmHashNext@Base 2.3.1
+ drmMalloc@Base 2.3.1
+ drmMap@Base 2.3.1
+ drmMapBufs@Base 2.3.1
+ drmMarkBufs@Base 2.3.1
+ drmMsg@Base 2.4.1
+ drmOpen@Base 2.3.1
+ drmOpenOnce@Base 2.3.1
+ drmRandom@Base 2.3.1
+ drmRandomCreate@Base 2.3.1
+ drmRandomDestroy@Base 2.3.1
+ drmRandomDouble@Base 2.3.1
+ drmRmMap@Base 2.3.1
+ drmSLCreate@Base 2.3.1
+ drmSLDelete@Base 2.3.1
+ drmSLDestroy@Base 2.3.1
+ drmSLDump@Base 2.3.1
+ drmSLFirst@Base 2.3.1
+ drmSLInsert@Base 2.3.1
+ drmSLLookup@Base 2.3.1
+ drmSLLookupNeighbors@Base 2.3.1
+ drmSLNext@Base 2.3.1
+ drmScatterGatherAlloc@Base 2.3.1
+ drmScatterGatherFree@Base 2.3.1
+ drmSetBusid@Base 2.3.1
+ drmSetContextFlags@Base 2.3.1
+ drmSetDebugMsgFunction@Base 2.3.1
+ drmSetInterfaceVersion@Base 2.3.1
+ drmSetServerInfo@Base 2.3.1
+ drmSwitchToContext@Base 2.3.1
+ drmUnlock@Base 2.3.1
+ drmUnmap@Base 2.3.1
+ drmUnmapBufs@Base 2.3.1
+ drmUpdateDrawableInfo@Base 2.3.1
+ drmWaitVBlank@Base 2.3.1
+libdrm_intel.so.1 libdrm2 #MINVER#
+ drm_intel_bo_alloc@Base 2.4.1
+ drm_intel_bo_emit_reloc@Base 2.4.1
+ drm_intel_bo_exec@Base 2.4.1
+ drm_intel_bo_fake_alloc_static@Base 2.4.1
+ drm_intel_bo_fake_disable_backing_store@Base 2.4.1
+ drm_intel_bo_flink@Base 2.4.1
+ drm_intel_bo_gem_create_from_name@Base 2.4.1
+ drm_intel_bo_get_subdata@Base 2.4.1
+ drm_intel_bo_get_tiling@Base 2.4.1
+ drm_intel_bo_map@Base 2.4.1
+ drm_intel_bo_pin@Base 2.4.1
+ drm_intel_bo_reference@Base 2.4.1
+ drm_intel_bo_set_tiling@Base 2.4.1
+ drm_intel_bo_subdata@Base 2.4.1
+ drm_intel_bo_unmap@Base 2.4.1
+ drm_intel_bo_unpin@Base 2.4.1
+ drm_intel_bo_unreference@Base 2.4.1
+ drm_intel_bo_wait_rendering@Base 2.4.1
+ drm_intel_bufmgr_check_aperture_space@Base 2.4.1
+ drm_intel_bufmgr_destroy@Base 2.4.1
+ drm_intel_bufmgr_fake_contended_lock_take@Base 2.4.1
+ drm_intel_bufmgr_fake_evict_all@Base 2.4.1
+ drm_intel_bufmgr_fake_init@Base 2.4.1
+ drm_intel_bufmgr_fake_set_exec_callback@Base 2.4.1
+ drm_intel_bufmgr_fake_set_fence_callback@Base 2.4.1
+ drm_intel_bufmgr_fake_set_last_dispatch@Base 2.4.1
+ drm_intel_bufmgr_gem_enable_reuse@Base 2.4.1
+ drm_intel_bufmgr_gem_init@Base 2.4.1
+ drm_intel_bufmgr_set_debug@Base 2.4.1
+ drm_mmAllocMem@Base 2.4.1
+ drm_mmDestroy@Base 2.4.1
+ drm_mmDumpMemInfo@Base 2.4.1
+ drm_mmFindBlock@Base 2.4.1
+ drm_mmFreeMem@Base 2.4.1
+ drm_mmInit@Base 2.4.1
diff --git a/debian/rules b/debian/rules
index e3659d9..e77d3dd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -91,7 +91,7 @@ binary-arch: build install
dh_strip
dh_compress
dh_fixperms
- dh_makeshlibs
+ dh_makeshlibs -- -c4
dh_installdeb
dh_shlibdeps
dh_gencontrol
commit 5c2320151e7f5a25e9fdfc5e08cf0fa3f7bec79c
Author: Timo Aaltonen <tjaalton@cc.hut.fi>
Date: Tue Nov 25 11:39:24 2008 +0200
clean unneeded *-core/ left from the merge.
diff --git a/bsd-core/i915_suspend.c b/bsd-core/i915_suspend.c
deleted file mode 120000
index b55754c..0000000
--- a/bsd-core/i915_suspend.c
+++ /dev/null
@@ -1 +0,0 @@
-../shared-core/i915_suspend.c
\ No newline at end of file
diff --git a/bsd-core/radeon_microcode.h b/bsd-core/radeon_microcode.h
deleted file mode 120000
index 709fff3..0000000
--- a/bsd-core/radeon_microcode.h
+++ /dev/null
@@ -1 +0,0 @@
-../shared-core/radeon_microcode.h
\ No newline at end of file
diff --git a/linux-core/drm-gem.txt b/linux-core/drm-gem.txt
deleted file mode 100644
index 5cda87f..0000000
--- a/linux-core/drm-gem.txt
+++ /dev/null
@@ -1,805 +0,0 @@
- The Graphics Execution Manager
- Part of the Direct Rendering Manager
- ==============================
-
- Keith Packard <keithp@keithp.com>
- Eric Anholt <eric@anholt.net>
- 2008-5-9
-
-Contents:
-
- 1. GEM Overview
- 2. API overview and conventions
- 3. Object Creation/Destruction
- 4. Reading/writing contents
- 5. Mapping objects to userspace
- 6. Memory Domains
- 7. Execution (Intel specific)
- 8. Other misc Intel-specific functions
-
-1. Graphics Execution Manager Overview
-
-Gem is designed to manage graphics memory, control access to the graphics
-device execution context and handle the essentially NUMA environment unique
-to modern graphics hardware. Gem allows multiple applications to share
-graphics device resources without the need to constantly reload the entire
-graphics card. Data may be shared between multiple applications with gem
-ensuring that the correct memory synchronization occurs.
-
-Graphics data can consume arbitrary amounts of memory, with 3D applications
-constructing ever larger sets of textures and vertices. With graphics cards
-memory space growing larger every year, and graphics APIs growing more
-complex, we can no longer insist that each application save a complete copy
-of their graphics state so that the card can be re-initialized from user
-space at each context switch. Ensuring that graphics data remains persistent
-across context switches allows applications significant new functionality
-while also improving performance for existing APIs.
-
-Modern linux desktops include significant 3D rendering as a fundemental
-component of the desktop image construction process. 2D and 3D applications
-paint their content to offscreen storage and the central 'compositing
-manager' constructs the final screen image from those window contents. This
-means that pixel image data from these applications must move within reach
-of the compositing manager and used as source operands for screen image
-rendering operations.
-
-Gem provides simple mechanisms to manage graphics data and control execution
-flow within the linux operating system. Using many existing kernel
-subsystems, it does this with a modest amount of code.
-
-2. API Overview and Conventions
-
-All APIs here are defined in terms of ioctls appplied to the DRM file
-descriptor. To create and manipulate objects, an application must be
-'authorized' using the DRI or DRI2 protocols with the X server. To relax
-that, we will need to implement some better access control mechanisms within
-the hardware portion of the driver to prevent inappropriate
-cross-application data access.
-
-Any DRM driver which does not support GEM will return -ENODEV for all of
-these ioctls. Invalid object handles return -EINVAL. Invalid object names
-return -ENOENT. Other errors are as documented in the specific API below.
-
-To avoid the need to translate ioctl contents on mixed-size systems (with
-32-bit user space running on a 64-bit kernel), the ioctl data structures
-contain explicitly sized objects, using 64-bits for all size and pointer
-data and 32-bits for identifiers. In addition, the 64-bit objects are all
-carefully aligned on 64-bit boundaries. Because of this, all pointers in the
-ioctl data structures are passed as uint64_t values. Suitable casts will
-be necessary.
-
-One significant operation which is explicitly left out of this API is object
-locking. Applications are expected to perform locking of shared objects
-outside of the GEM api. This kind of locking is not necessary to safely
-manipulate the graphics engine, and with multiple objects interacting in
-unknown ways, per-object locking would likely introduce all kinds of
-lock-order issues. Punting this to the application seems like the only
-sensible plan. Given that DRM already offers a global lock on the hardware,
-this doesn't change the current situation.
-
-3. Object Creation and Destruction
-
-Gem provides explicit memory management primitives. System pages are
-allocated when the object is created, either as the fundemental storage for
-hardware where system memory is used by the graphics processor directly, or
-as backing store for graphics-processor resident memory.
-
-Objects are referenced from user space using handles. These are, for all
-intents and purposes, equivalent to file descriptors. We could simply use
-file descriptors were it not for the small limit (1024) of file descriptors
-available to applications, and for the fact that the X server (a rather
-significant user of this API) uses 'select' and has a limited maximum file
-descriptor for that operation. Given the ability to allocate more file
-descriptors, and given the ability to place these 'higher' in the file
-descriptor space, we'd love to simply use file descriptors.
-
-Objects may be published with a name so that other applications can access
-them. The name remains valid as long as the object exists. Right now, our
-DRI APIs use 32-bit integer names, so that's what we expose here
-
- A. Creation
-
- struct drm_gem_create {
- /**
- * Requested size for the object.
- *
- * The (page-aligned) allocated size for the object
- * will be returned.
- */
- uint64_t size;
- /**
- * Returned handle for the object.
- *
- * Object handles are nonzero.
- */
- uint32_t handle;
- uint32_t pad;
- };
-
- /* usage */
- create.size = 16384;
- ret = ioctl (fd, DRM_IOCTL_GEM_CREATE, &create);
- if (ret == 0)
- return create.handle;
-
- Note that the size is rounded up to a page boundary, and that
- the rounded-up size is returned in 'size'. No name is assigned to
- this object, making it local to this process.
-
- If insufficient memory is availabe, -ENOMEM will be returned.
-
- B. Closing
-
- struct drm_gem_close {
- /** Handle of the object to be closed. */
- uint32_t handle;
- uint32_t pad;
- };
-
-
- /* usage */
- close.handle = <handle>;
- ret = ioctl (fd, DRM_IOCTL_GEM_CLOSE, &close);
-
- This call makes the specified handle invalid, and if no other
- applications are using the object, any necessary graphics hardware
- synchronization is performed and the resources used by the object
- released.
-
- C. Naming
-
- struct drm_gem_flink {
- /** Handle for the object being named */
- uint32_t handle;
-
- /** Returned global name */
- uint32_t name;
- };
-
- /* usage */
- flink.handle = <handle>;
- ret = ioctl (fd, DRM_IOCTL_GEM_FLINK, &flink);
- if (ret == 0)
- return flink.name;
-
- Flink creates a name for the object and returns it to the
- application. This name can be used by other applications to gain
- access to the same object.
-
- D. Opening by name
-
- struct drm_gem_open {
- /** Name of object being opened */
- uint32_t name;
-
- /** Returned handle for the object */
- uint32_t handle;
-
- /** Returned size of the object */
- uint64_t size;
- };
-
- /* usage */
- open.name = <name>;
- ret = ioctl (fd, DRM_IOCTL_GEM_OPEN, &open);
- if (ret == 0) {
- *sizep = open.size;
- return open.handle;
- }
-
- Open accesses an existing object and returns a handle for it. If the
- object doesn't exist, -ENOENT is returned. The size of the object is
- also returned. This handle has all the same capabilities as the
- handle used to create the object. In particular, the object is not
- destroyed until all handles are closed.
-
-4. Basic read/write operations
-
-By default, gem objects are not mapped to the applications address space,
-getting data in and out of them is done with I/O operations instead. This
-allows the data to reside in otherwise unmapped pages, including pages in
-video memory on an attached discrete graphics card. In addition, using
-explicit I/O operations allows better control over cache contents, as
-graphics devices are generally not cache coherent with the CPU, mapping
-pages used for graphics into an application address space requires the use
-of expensive cache flushing operations. Providing direct control over
-graphics data access ensures that data are handled in the most efficient
-possible fashion.
-
- A. Reading
-
- struct drm_gem_pread {
- /** Handle for the object being read. */
- uint32_t handle;
- uint32_t pad;
- /** Offset into the object to read from */
- uint64_t offset;
- /** Length of data to read */
- uint64_t size;
- /** Pointer to write the data into. */
- uint64_t data_ptr; /* void * */
- };
-
- This copies data into the specified object at the specified
- position. Any necessary graphics device synchronization and
- flushing will be done automatically.
-
- struct drm_gem_pwrite {
- /** Handle for the object being written to. */
- uint32_t handle;
- uint32_t pad;
- /** Offset into the object to write to */
- uint64_t offset;
- /** Length of data to write */
- uint64_t size;
- /** Pointer to read the data from. */
- uint64_t data_ptr; /* void * */
- };
-
- This copies data out of the specified object into the
- waiting user memory. Again, device synchronization will
- be handled by the kernel to ensure user space sees a
- consistent view of the graphics device.
-
-5. Mapping objects to user space
-
-For most objects, reading/writing is the preferred interaction mode.
-However, when the CPU is involved in rendering to cover deficiencies in
-hardware support for particular operations, the CPU will want to directly
-access the relevant objects.
-
-Because mmap is fairly heavyweight, we allow applications to retain maps to
-objects persistently and then update how they're using the memory through a
-separate interface. Applications which fail to use this separate interface
-may exhibit unpredictable behaviour as memory consistency will not be
-preserved.
-
- A. Mapping
-
- struct drm_gem_mmap {
- /** Handle for the object being mapped. */
- uint32_t handle;
- uint32_t pad;
- /** Offset in the object to map. */
- uint64_t offset;
- /**
- * Length of data to map.
- *
- * The value will be page-aligned.
- */
- uint64_t size;
- /** Returned pointer the data was mapped at */
- uint64_t addr_ptr; /* void * */
- };
-
- /* usage */
- mmap.handle = <handle>;
- mmap.offset = <offset>;
- mmap.size = <size>;
- ret = ioctl (fd, DRM_IOCTL_GEM_MMAP, &mmap);
- if (ret == 0)
- return (void *) (uintptr_t) mmap.addr_ptr;
-
-
- B. Unmapping
-
- munmap (addr, length);
-
- Nothing strange here, just use the normal munmap syscall.
-
-6. Memory Domains
-
-Graphics devices remain a strong bastion of non cache-coherent memory. As a
-result, accessing data through one functional unit will end up loading that
-cache with data which then needs to be manually synchronized when that data
-is used with another functional unit.
-
-Tracking where data are resident is done by identifying how functional units
-deal with caches. Each cache is labeled as a separate memory domain. Then,
-each sequence of operations is expected to load data into various read
-domains and leave data in at most one write domain. Gem tracks the read and
-write memory domains of each object and performs the necessary
-synchronization operations when objects move from one domain set to another.
-
-For example, if operation 'A' constructs an image that is immediately used
-by operation 'B', then when the read domain for 'B' is not the same as the
-write domain for 'A', then the write domain must be flushed, and the read
-domain invalidated. If these two operations are both executed in the same
-command queue, then the flush operation can go inbetween them in the same
-queue, avoiding any kind of CPU-based synchronization and leaving the GPU to
-do the work itself.
-
-6.1 Memory Domains (GPU-independent)
-
- * DRM_GEM_DOMAIN_CPU.
-
- Objects in this domain are using caches which are connected to the CPU.
- Moving objects from non-CPU domains into the CPU domain can involve waiting
- for the GPU to finish with operations using this object. Moving objects
- from this domain to a GPU domain can involve flushing CPU caches and chipset
- buffers.
-
-6.1 GPU-independent memory domain ioctl
-
-This ioctl is independent of the GPU in use. So far, no use other than
-synchronizing objects to the CPU domain have been found; if that turns out
-to be generally true, this ioctl may be simplified further.
-
- A. Explicit domain control
-
- struct drm_gem_set_domain {
- /** Handle for the object */
- uint32_t handle;
-
- /** New read domains */
- uint32_t read_domains;
-
- /** New write domain */
- uint32_t write_domain;
- };
-
- /* usage */
- set_domain.handle = <handle>;
- set_domain.read_domains = <read_domains>;
- set_domain.write_domain = <write_domain>;
- ret = ioctl (fd, DRM_IOCTL_GEM_SET_DOMAIN, &set_domain);
-
- When the application wants to explicitly manage memory domains for
- an object, it can use this function. Usually, this is only used
- when the application wants to synchronize object contents between
- the GPU and CPU-based application rendering. In that case,
- the <read_domains> would be set to DRM_GEM_DOMAIN_CPU, and if the
- application were going to write to the object, the <write_domain>
- would also be set to DRM_GEM_DOMAIN_CPU. After the call, gem
- guarantees that all previous rendering operations involving this
- object are complete. The application is then free to access the
- object through the address returned by the mmap call. Afterwards,
- when the application again uses the object through the GPU, any
- necessary CPU flushing will occur and the object will be correctly
- synchronized with the GPU.
-
- Note that this synchronization is not required for any accesses
- going through the driver itself. The pread, pwrite and execbuffer
- ioctls all perform the necessary domain management internally.
- Explicit synchronization is only necessary when accessing the object
- through the mmap'd address.
-
-7. Execution (Intel specific)
-
-Managing the command buffers is inherently chip-specific, so the core of gem
-doesn't have any intrinsic functions. Rather, execution is left to the
-device-specific portions of the driver.
-
-The Intel DRM_I915_GEM_EXECBUFFER ioctl takes a list of gem objects, all of
-which are mapped to the graphics device. The last object in the list is the
-command buffer.
-
-7.1. Relocations
-
-Command buffers often refer to other objects, and to allow the kernel driver
-to move objects around, a sequence of relocations is associated with each
-object. Device-specific relocation operations are used to place the
-target-object relative value into the object.
-
-The Intel driver has a single relocation type:
-
- struct drm_i915_gem_relocation_entry {
- /**
- * Handle of the buffer being pointed to by this
- * relocation entry.
- *
- * It's appealing to make this be an index into the
- * mm_validate_entry list to refer to the buffer,
- * but this allows the driver to create a relocation
- * list for state buffers and not re-write it per
- * exec using the buffer.
- */
- uint32_t target_handle;
-
- /**
- * Value to be added to the offset of the target
- * buffer to make up the relocation entry.
- */
- uint32_t delta;
-
- /**
- * Offset in the buffer the relocation entry will be
- * written into
- */
- uint64_t offset;
-
- /**
- * Offset value of the target buffer that the
- * relocation entry was last written as.
- *
- * If the buffer has the same offset as last time, we
- * can skip syncing and writing the relocation. This
- * value is written back out by the execbuffer ioctl
- * when the relocation is written.
- */
- uint64_t presumed_offset;
-
- /**
- * Target memory domains read by this operation.
- */
- uint32_t read_domains;
-
- /*
- * Target memory domains written by this operation.
- *
- * Note that only one domain may be written by the
- * whole execbuffer operation, so that where there are
- * conflicts, the application will get -EINVAL back.
- */
- uint32_t write_domain;
- };
-
- 'target_handle', the handle to the target object. This object must
- be one of the objects listed in the execbuffer request or
- bad things will happen. The kernel doesn't check for this.
-
- 'offset' is where, in the source object, the relocation data
- are written. Each relocation value is a 32-bit value consisting
- of the location of the target object in the GPU memory space plus
- the 'delta' value included in the relocation.
-
- 'presumed_offset' is where user-space believes the target object
- lies in GPU memory space. If this value matches where the object
- actually is, then no relocation data are written, the kernel
- assumes that user space has set up data in the source object
- using this presumption. This offers a fairly important optimization
- as writing relocation data requires mapping of the source object
- into the kernel memory space.
-
- 'read_domains' and 'write_domains' list the usage by the source
- object of the target object. The kernel unions all of the domain
- information from all relocations in the execbuffer request. No more
- than one write_domain is allowed, otherwise an EINVAL error is
- returned. read_domains must contain write_domain. This domain
- information is used to synchronize buffer contents as described
- above in the section on domains.
-
-7.1.1 Memory Domains (Intel specific)
-
-The Intel GPU has several internal caches which are not coherent and hence
-require explicit synchronization. Memory domains provide the necessary data
-to synchronize what is needed while leaving other cache contents intact.
-
- * DRM_GEM_DOMAIN_I915_RENDER.
- The GPU 3D and 2D rendering operations use a unified rendering cache, so
- operations doing 3D painting and 2D blts will use this domain
-
- * DRM_GEM_DOMAIN_I915_SAMPLER
- Textures are loaded by the sampler through a separate cache, so
- any texture reading will use this domain. Note that the sampler
- and renderer use different caches, so moving an object from render target
- to texture source will require a domain transfer.
-
- * DRM_GEM_DOMAIN_I915_COMMAND
- The command buffer doesn't have an explicit cache (although it does
- read ahead quite a bit), so this domain just indicates that the object
- needs to be flushed to the GPU.
-
- * DRM_GEM_DOMAIN_I915_INSTRUCTION
- All of the programs on Gen4 and later chips use an instruction cache to
- speed program execution. It must be explicitly flushed when new programs
- are written to memory by the CPU.
-
- * DRM_GEM_DOMAIN_I915_VERTEX
- Vertex data uses two different vertex caches, but they're
- both flushed with the same instruction.
-
-7.2 Execution object list (Intel specific)
-
- struct drm_i915_gem_exec_object {
- /**
- * User's handle for a buffer to be bound into the GTT
- * for this operation.
- */
- uint32_t handle;
-
- /**
- * List of relocations to be performed on this buffer
- */
- uint32_t relocation_count;
- /* struct drm_i915_gem_relocation_entry *relocs */
- uint64_t relocs_ptr;
-
- /**
- * Required alignment in graphics aperture
- */
- uint64_t alignment;
-
- /**
- * Returned value of the updated offset of the object,
- * for future presumed_offset writes.
- */
- uint64_t offset;
- };
-
- Each object involved in a particular execution operation must be
- listed using one of these structures.
-
- 'handle' references the object.
-
- 'relocs_ptr' is a user-mode pointer to a array of 'relocation_count'
- drm_i915_gem_relocation_entry structs (see above) that
- define the relocations necessary in this buffer. Note that all
- relocations must reference other exec_object structures in the same
- execbuffer ioctl and that those other buffers must come earlier in
- the exec_object array. In other words, the dependencies mapped by the
- exec_object relocations must form a directed acyclic graph.
-
- 'alignment' is the byte alignment necessary for this buffer. Each
- object has specific alignment requirements, as the kernel doesn't
- know what each object is being used for, those requirements must be
- provided by user mode. If an object is used in two different ways,
- it's quite possible that the alignment requirements will differ.
-
- 'offset' is a return value, receiving the location of the object
- during this execbuffer operation. The application should use this
- as the presumed offset in future operations; if the object does not
- move, then kernel need not write relocation data.
-
-7.3 Execbuffer ioctl (Intel specific)
-
- struct drm_i915_gem_execbuffer {
- /**
- * List of buffers to be validated with their
- * relocations to be performend on them.
- *
- * These buffers must be listed in an order such that
- * all relocations a buffer is performing refer to
- * buffers that have already appeared in the validate
- * list.
- */
- /* struct drm_i915_gem_validate_entry *buffers */
- uint64_t buffers_ptr;
- uint32_t buffer_count;
-
- /**
- * Offset in the batchbuffer to start execution from.
- */
- uint32_t batch_start_offset;
-
- /**
- * Bytes used in batchbuffer from batch_start_offset
- */
- uint32_t batch_len;
- uint32_t DR1;
- uint32_t DR4;
- uint32_t num_cliprects;
- uint64_t cliprects_ptr; /* struct drm_clip_rect *cliprects */
- };
-
-
- 'buffers_ptr' is a user-mode pointer to an array of 'buffer_count'
- drm_i915_gem_exec_object structures which contains the complete set
- of objects required for this execbuffer operation. The last entry in
- this array, the 'batch buffer', is the buffer of commands which will
- be linked to the ring and executed.
-
- 'batch_start_offset' is the byte offset within the batch buffer which
- contains the first command to execute. So far, we haven't found a
- reason to use anything other than '0' here, but the thought was that
- some space might be allocated for additional initialization which
- could be skipped in some cases. This must be a multiple of 4.
-
- 'batch_len' is the length, in bytes, of the data to be executed
- (i.e., the amount of data after batch_start_offset). This must
- be a multiple of 4.
-
- 'num_cliprects' and 'cliprects_ptr' reference an array of
- drm_clip_rect structures that is num_cliprects long. The entire
- batch buffer will be executed multiple times, once for each
- rectangle in this list. If num_cliprects is 0, then no clipping
- rectangle will be set.
-
- 'DR1' and 'DR4' are portions of the 3DSTATE_DRAWING_RECTANGLE
- command which will be queued when this operation is clipped
- (num_cliprects != 0).
-
- DR1 bit definition
- 31 Fast Scissor Clip Disable (debug only).
- Disables a hardware optimization that
- improves performance. This should have
- no visible effect, other than reducing
- performance
-
- 30 Depth Buffer Coordinate Offset Disable.
- This disables the addition of the
- depth buffer offset bits which are used
- to change the location of the depth buffer
- relative to the front buffer.
-
- 27:26 X Dither Offset. Specifies the X pixel
- offset to use when accessing the dither table
-
- 25:24 Y Dither Offset. Specifies the Y pixel
- offset to use when accessing the dither
- table.
-
- DR4 bit definition
- 31:16 Drawing Rectangle Origin Y. Specifies the Y
- origin of coordinates relative to the
- draw buffer.
-
- 15:0 Drawing Rectangle Origin X. Specifies the X
- origin of coordinates relative to the
- draw buffer.
-
- As you can see, these two fields are necessary for correctly
- offsetting drawing within a buffer which contains multiple surfaces.
- Note that DR1 is only used on Gen3 and earlier hardware and that
- newer hardware sticks the dither offset elsewhere.
-
-7.3.1 Detailed Execution Description
-
- Execution of a single batch buffer requires several preparatory
- steps to make the objects visible to the graphics engine and resolve
- relocations to account for their current addresses.
-
- A. Mapping and Relocation
-
- Each exec_object structure in the array is examined in turn.
-
- If the object is not already bound to the GTT, it is assigned a
- location in the graphics address space. If no space is available in
- the GTT, some other object will be evicted. This may require waiting
- for previous execbuffer requests to complete before that object can
- be unmapped. With the location assigned, the pages for the object
- are pinned in memory using find_or_create_page and the GTT entries
- updated to point at the relevant pages using drm_agp_bind_pages.
-
- Then the array of relocations is traversed. Each relocation record
- looks up the target object and, if the presumed offset does not
- match the current offset (remember that this buffer has already been
- assigned an address as it must have been mapped earlier), the
- relocation value is computed using the current offset. If the
- object is currently in use by the graphics engine, writing the data
- out must be preceeded by a delay while the object is still busy.
- Once it is idle, then the page containing the relocation is mapped
- by the CPU and the updated relocation data written out.
-
- The read_domains and write_domain entries in each relocation are
- used to compute the new read_domains and write_domain values for the
- target buffers. The actual execution of the domain changes must wait
- until all of the exec_object entries have been evaluated as the
- complete set of domain information will not be available until then.
-
- B. Memory Domain Resolution
-
- After all of the new memory domain data has been pulled out of the
- relocations and computed for each object, the list of objects is
- again traversed and the new memory domains compared against the
- current memory domains. There are two basic operations involved here:
-
- * Flushing the current write domain. If the new read domains
- are not equal to the current write domain, then the current
- write domain must be flushed. Otherwise, reads will not see data
- present in the write domain cache. In addition, any new read domains
- other than the current write domain must be invalidated to ensure
- that the flushed data are re-read into their caches.
-
- * Invaliding new read domains. Any domains which were not currently
- used for this object must be invalidated as old objects which
- were mapped at the same location may have stale data in the new
- domain caches.
-
- If the CPU cache is being invalidated and some GPU cache is being
- flushed, then we'll have to wait for rendering to complete so that
- any pending GPU writes will be complete before we flush the GPU
- cache.
-
- If the CPU cache is being flushed, then we use 'clflush' to get data
- written from the CPU.
-
- Because the GPU caches cannot be partially flushed or invalidated,
- we don't actually flush them during this traversal stage. Rather, we
- gather the invalidate and flush bits up in the device structure.
-
- Once all of the object domain changes have been evaluated, then the
- gathered invalidate and flush bits are examined. For any GPU flush
- operations, we emit a single MI_FLUSH command that performs all of
- the necessary flushes. We then look to see if the CPU cache was
- flushed. If so, we use the chipset flush magic (writing to a special
- page) to get the data out of the chipset and into memory.
-
- C. Queuing Batch Buffer to the Ring
-
- With all of the objects resident in graphics memory space, and all
- of the caches prepared with appropriate data, the batch buffer
- object can be queued to the ring. If there are clip rectangles, then
- the buffer is queued once per rectangle, with suitable clipping
- inserted into the ring just before the batch buffer.
-
- D. Creating an IRQ Cookie
-
- Right after the batch buffer is placed in the ring, a request to
- generate an IRQ is added to the ring along with a command to write a
- marker into memory. When the IRQ fires, the driver can look at the
- memory location to see where in the ring the GPU has passed. This
- magic cookie value is stored in each object used in this execbuffer
- command; it is used whereever you saw 'wait for rendering' above in
- this document.
-
- E. Writing back the new object offsets
-
- So that the application has a better idea what to use for
- 'presumed_offset' values later, the current object offsets are
- written back to the exec_object structures.
-
-
-8. Other misc Intel-specific functions.
-
-To complete the driver, a few other functions were necessary.
-
-8.1 Initialization from the X server
-
-As the X server is currently responsible for apportioning memory between 2D
-and 3D, it must tell the kernel which region of the GTT aperture is
-available for 3D objects to be mapped into.
-
- struct drm_i915_gem_init {
- /**
- * Beginning offset in the GTT to be managed by the
- * DRM memory manager.
- */
- uint64_t gtt_start;
- /**
- * Ending offset in the GTT to be managed by the DRM
- * memory manager.
- */
- uint64_t gtt_end;
Reply to: