| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
No need to fill the ring that much; wait for it to become nearly empty
before adding the execbuffer request. A better fix will involve scheduling
ring insertion in the irq handler.
|
|
If the ring is full, the engine will surely be running for more than 10ms.
|
|
Leave the flush call in place, which can fix domains up if necessary.
|
|
|
|
pread and pwrite must update the memory domains to ensure consistency with
the GPU. At some point, it should be possible to avoid clflush through this
path, but that isn't working for me.
|
|
The exec list contains all objects, in order of use. The lru list contains
only unpinned objects ready to be evicted. This required two changes -- the
first was to not migrate pinned objects from exec to lru, the second was to
search for the first unpinned object in the exec list when doing eviction.
|
|
|
|
Add some API and implementation documentation for GEM.
|
|
Rename 'validate_entry' to 'exec_object', then clean up some field names in
structures (renaming buffer_offset to just offset, for example).
|
|
It takes (offset, size), not (offset, end).
|
|
Now, the LRU list has objects that are completely done rendering and ready
to kick out, while the execution list has things with active rendering,
which have associated cookies and reference counts on them.
|
|
Still managing to get something wrong with this, oopsing down in agp.
|
|
|
|
Make the API names a bit more consistent.
|
|
|
|
Whitespace changes, a few too-long-lines and some extra braces.
|
|
|
|
Domain information is about buffer relationships, not buffer contents. That
means a relocation contains the domain information as it knows how the
source buffer references the target buffer.
This also adds the set_domain ioctl so that user space can move buffers to
the cpu domain.
|
|
|
|
|
|
This should already have been generally safe since we don't change contents
and put in new relocations between execbufs, so if we were writing in a new
relocation then we'd already waited rendering to complete when we moved
the target of the relocation. However, doing the right thing will be required
if we do buffer reuse.
|
|
One of our MI_FLUSH bits is reserved on 965, being always implied, and there's
a vertex cache that was forgotten.
|
|
If objects on the lru aren't ref counted, they'll get pulled from the gtt as
soon as they are freed. This change does cause objects to get stuck in the
gtt until they're forced out by new requests. The lru should get cleaned
when the irq occurs.
|
|
Memory domains allow the kernel to track which caches to flush and how to
move objects before buffer execution.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When batch buffers are executing, the ring may be stuck for a long time.
Monitor the ACTHD pointer which will show if the execution engine is
actually hung.
|
|
pages come back from find_or_create_page locked, but must not stay locked
for long. Unlock them immediately instead of waiting until we're done with
them to avoid deadlock when applications try to touch them.
|
|
Conflicts:
linux-core/i915_gem.c
|
|
I was wrong about how the data structure worked, and didn't care to fix it
to support debugging code.
|
|
|
|
The relocated value was being written to the wrong location, missing
the object base address.
|
|
|
|
|
|
This function submits a gem-based execbuffer to the ring.
It doesn't work yet.
|
|
|
|
|
|
|
|
Track named objects in /proc/dri/0/gem_names.
Track total object count in /proc/dri/0/gem_objects.
Initialize device gem data.
return -ENODEV for gem ioctls if the driver doesn't support gem.
Call unlock_page when unbinding from gtt.
Add numerous misssing calls to drm_gem_object_unreference.
|
|
Names are just another unique integer set (from another idr object).
Names are removed when the user refernces (handles) are all destroyed --
this required that handles for objects be counted separately from
internal kernel references (so that we can tell when the handles are all
gone).
|
|
Now that drm_gem_object has a drm_driver * in it, functions don't need both
parameters.
|
|
|
|
When pinning buffers, or using execbuffer, allow the application to specify
the necessary aperture allocation alignment constraints.
|
|
mixed 32/64 bit systems need 'special' help for ioctl where the user-space
and kernel-space datatypes differ. Fixing the datatypes to be the same size,
and align the same way for both 32 and 64-bit ppc and x86 environments will
elimiante the need to have magic 32/64-bit ioctl translation code.
|
