Re: [Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-16 Thread Chris Wilson
On Tue, Jun 16, 2015 at 02:18:55PM +0200, Daniel Vetter wrote: > Maybe someone should look at per-buffer locks before trying to split up > the low-level hw locks ;-) Per-vm then per-buffer. Adding more locked operations to execbuf is scary though, with some workloads perf highlights the cost of th

Re: [Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-16 Thread Daniel Vetter
On Tue, Jun 16, 2015 at 12:03:45PM +0100, Dave Gordon wrote: > On 15/06/15 21:41, Chris Wilson wrote: > > On Mon, Jun 15, 2015 at 07:11:37PM +0100, Dave Gordon wrote: > >>> It still applies. If you submit say 1024 interrupted execbuffers they > >> > >> What is an interrupted execbuffer? AFAICT we h

Re: [Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-16 Thread Dave Gordon
On 15/06/15 21:41, Chris Wilson wrote: > On Mon, Jun 15, 2015 at 07:11:37PM +0100, Dave Gordon wrote: >>> It still applies. If you submit say 1024 interrupted execbuffers they >> >> What is an interrupted execbuffer? AFAICT we hold the struct_mutex while >> stuffing the ringbuffer so we can only ev

Re: [Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-15 Thread Chris Wilson
On Mon, Jun 15, 2015 at 07:11:37PM +0100, Dave Gordon wrote: > > It still applies. If you submit say 1024 interrupted execbuffers they > > What is an interrupted execbuffer? AFAICT we hold the struct_mutex while > stuffing the ringbuffer so we can only ever be in the process of adding > instructio

Re: [Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-15 Thread Dave Gordon
On 15/06/15 10:15, Chris Wilson wrote: > On Mon, Jun 08, 2015 at 07:51:36PM +0100, Dave Gordon wrote: >> The original idea of preallocating the OLR was implemented in >> >>> 9d773091 drm/i915: Preallocate next seqno before touching the ring >> >> and the sequence of operations was to allocate the O

Re: [Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-15 Thread Chris Wilson
On Mon, Jun 08, 2015 at 07:51:36PM +0100, Dave Gordon wrote: > The original idea of preallocating the OLR was implemented in > > > 9d773091 drm/i915: Preallocate next seqno before touching the ring > > and the sequence of operations was to allocate the OLR, then wrap past > the end of the ring if

Re: [Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-13 Thread shuang . he
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6557 -Summary- Platform Delta drm-intel-nightly Series Applied PNV

[Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-08 Thread Dave Gordon
The original idea of preallocating the OLR was implemented in > 9d773091 drm/i915: Preallocate next seqno before touching the ring and the sequence of operations was to allocate the OLR, then wrap past the end of the ring if necessary, then wait for space if necessary. But subsequently intel_ring