| Age | Commit message (Collapse) | Author |
|---|
|
Use new GEM based ring buffer initialization. Still need to init GEM & use it
for framebuffer allocation etc.
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
|
|
This requires that the X Server use the execbuf interface for buffer
submission, as it no longer has direct access to the ring. This is
therefore a flag day for the gem interface.
This also adds enter/leavevt ioctls for use by the X Server. These would
get stubbed out in a modesetting implementation, but are required while
in an environment where the device's state is only managed by the DRM while
X has the VT.
|
|
Passed the compile test; it's ready to ship.
Conflicts:
libdrm/Makefile.am
linux-core/Makefile.kernel
linux-core/drmP.h
linux-core/drm_memrange.c
linux-core/drm_stub.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
The driver can know what hardware requires MI_BATCH_BUFFER vs
MI_BATCH_BUFFER_START; there's no reason to let user mode configure this.
|
|
The driver can know what hardware requires MI_BATCH_BUFFER vs
MI_BATCH_BUFFER_START; there's no reason to let user mode configure this.
|
|
Without the user IRQ running constantly, there's no wakeup when the ring
empties to go retire requests and free buffers. Use a 1 second timer to make
that happen more often.
|
|
This goes with the other hardware status page patch.
|
|
Instead of throttling and execbuffer time, have the application ask to
throttle explicitly. This allows the throttle to happen less often, and
without holding the DRM lock.
|
|
I couldn't get the re-allocated HWS to work on my 965GM, so I just gave up
and made it persist across the lifetime of the driver instead.
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
shared-core/i915_drv.h
shared-core/nouveau_state.c
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
|
|
The i915 driver now works again.
|
|
This new ioctl returns whether re-using the buffer would force a wait.
|
|
Recording the tail pointer in a local variable improves performance, but if
someone messes up and fails to reload at the right time, the driver will
write commands to the wrong part of the ring and scramble execution badly.
This change (available by setting I915_RING_VALIDATE to 1) checks to make
sure the cached tail pointer matches the hardware tail pointer at each ring
buffer addition, calling BUG_ON when that's not true.
|
|
There are now 3 lists. Active is buffers currently in the ringbuffer.
Flushing is not in the ringbuffer, but needs a flush before unbinding.
Inactive is as before. This prevents object_free → unbind →
wait_rendering → object_reference and a kernel oops about weird refcounting.
This also avoids an synchronous extra flush and wait when freeing a buffer
which had a write_domain set (such as a temporary rendered to and then from
using the 2d engine). It will sit around on the flushing list until the
appropriate flush gets emitted, or we need the GTT space for another
operation.
|
|
This lets us get some qualities we desire, such as using the full 32-bit
range (except zero), avoiding DRM_WAIT_ON, and a 1:1 mapping of active
sequence numbers to request structs, which will be used soon for throttling
and interrupt-driven list cleanup.
|
|
|
|
into modesetting-101
|
|
It would be nice if one day the DRM driver was the canonical source for
register definitions and core macros. To that end, this patch cleans
things up quite a bit, removing redundant definitions (some with
different names referring to the same register) and generally tidying up
the header file.
|
|
|
|
If the ring is full, the engine will surely be running for more than 10ms.
|
|
We need to alloc a hw status page bo for G33 if modeset is enabled since the 2D
driver can't alloc gfx memory when working in drm modeset.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
This function submits a gem-based execbuffer to the ring.
It doesn't work yet.
|
|
|
|
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/drm_compat.c
linux-core/drm_fops.c
linux-core/drm_lock.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
From Jesse and Zhenyu originally.
|
|
Kernel bug 10289.
|
|
Conflicts:
linux-core/drm_compat.c
linux-core/drm_compat.h
linux-core/drm_ttm.c
shared-core/i915_dma.c
Bump driver minor to 13 due to introduction of new
relocation type.
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_proc.c
linux-core/drm_stub.c
linux-core/drm_sysfs.c
|
|
Rip out the whole head thing and replace it with an idr and drm_minor
structure.
|
|
writting relocations, otherwise the GPU probably sees some
inconsistent data. Fix fd.o bug#14656
|
|
Conflicts:
linux-core/drm_compat.c
|
|
|
|
|
|
This change adds a driver feature that for i915 is controlled by a module
parameter. You now need to do insmod i915.ko modeset=1 to enable it the
modesetting paths.
It also fixes up lots of X paths. I can run my new DDX driver on this code
with and without modesetting enabled
|
|
|
|
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
|
|
|
