Ignoring the legacy DRI1 code, and a couple of special cases (to be
discussed later), all access to the ring is mediated through requests.
The first write to a ring will grab a seqno and mark the ring as having
an outstanding_lazy_request. Either through explicitly adding a request
after an execbuf
On Sat, Aug 10, 2013 at 10:17:39AM -0700, Ben Widawsky wrote:
> On Sat, Aug 10, 2013 at 10:58:30AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 09, 2013 at 10:12:12PM -0700, Ben Widawsky wrote:
> > > I just noticed in our code we don't really check the assertion, and
> > > given some of the code I a
On Sat, Aug 10, 2013 at 10:58:30AM +0200, Daniel Vetter wrote:
> On Fri, Aug 09, 2013 at 10:12:12PM -0700, Ben Widawsky wrote:
> > I just noticed in our code we don't really check the assertion, and
> > given some of the code I am changing in this area, I feel a WARN is very
> > nice to have.
> >
It can be useful to compare at times the current vs requested frequency
of the GPU, so provide the contents of RPNSWREQ alonside CAGF.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/d
On Sat, Aug 10, 2013 at 02:09:20PM +0100, Chris Wilson wrote:
> On Sat, Aug 10, 2013 at 02:57:27PM +0200, Daniel Vetter wrote:
> > Resolve the catch-22 of igt needing a stable number and patches first
> > needing testcases by reserving the interface number up-front.
> >
> > v2: Improve the spellin
On Sat, Aug 10, 2013 at 02:57:27PM +0200, Daniel Vetter wrote:
> Resolve the catch-22 of igt needing a stable number and patches first
> needing testcases by reserving the interface number up-front.
>
> v2: Improve the spelling a bit.
Missed CACHGING and s/not special/no special/
Otherwise,
Revie
Resolve the catch-22 of igt needing a stable number and patches first
needing testcases by reserving the interface number up-front.
v2: Improve the spelling a bit.
Requested-by: Chris Wilson
Cc: Chris Wilson
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 24
Resolve the catch-22 of igt needing a stable number and patches first
needing testcases by reserving the interface number up-front.
Requested-by: Chris Wilson
Cc: Chris Wilson
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 24
1 file
On Sat, Aug 10, 2013 at 12:09:26PM +0200, Daniel Vetter wrote:
> On Thu, Aug 08, 2013 at 02:41:11PM +0100, Chris Wilson wrote:
> > This is primarily for the benefit of the create2 ioctl so that the
> > caller can avoid the later step of rebinding the bo with new PTE bits.
> > After introducing WT (
On Thu, Aug 08, 2013 at 02:41:11PM +0100, Chris Wilson wrote:
> This is primarily for the benefit of the create2 ioctl so that the
> caller can avoid the later step of rebinding the bo with new PTE bits.
> After introducing WT (and possibly GFDT) cacheing for display targets,
> not everything in th
On Sat, Aug 10, 2013 at 10:34:29AM +0100, Chris Wilson wrote:
> On Sat, Aug 10, 2013 at 11:25:46AM +0200, Daniel Vetter wrote:
> > On Thu, Aug 08, 2013 at 02:41:08PM +0100, Chris Wilson wrote:
> > > Once again, the CPU PAT bits are irrelevant when considering the GPU
> > > cacheing, and context obj
On Sat, Aug 10, 2013 at 11:25:46AM +0200, Daniel Vetter wrote:
> On Thu, Aug 08, 2013 at 02:41:08PM +0100, Chris Wilson wrote:
> > Once again, the CPU PAT bits are irrelevant when considering the GPU
> > cacheing, and context objects are never accessed from the CPU or
> > directly by userspace maki
On Thu, Aug 08, 2013 at 02:41:08PM +0100, Chris Wilson wrote:
> Once again, the CPU PAT bits are irrelevant when considering the GPU
> cacheing, and context objects are never accessed from the CPU or
> directly by userspace making them another ideal candidate to allocate
> from stolen memory.
>
>
On Fri, Aug 09, 2013 at 10:12:16PM -0700, Ben Widawsky wrote:
> static int
> i915_gem_execbuffer_move_to_gpu(struct intel_ring_buffer *ring,
> - struct list_head *objects)
> + struct list_head *vmas)
> {
> - struct drm_i915_gem_object *
On Fri, Aug 09, 2013 at 10:12:16PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> In order to transition more of our code over to using a VMA instead of
> an pair - we must have the vma accessible at execbuf time. Up
> until now, we've only had a VMA when actually binding an object.
>
> Th
A follow-on to the update of the LLC coherency logic is that we can rely
on the LLC being coherent with the CS for rewriting batchbuffers
irrespective of their cache domain. (This should have no effect
currently as all the batch buffers are expected to be I915_CACHE_LLC and
so using the cpu relocat
On Fri, Aug 09, 2013 at 10:12:16PM -0700, Ben Widawsky wrote:
> static int
> -need_reloc_mappable(struct drm_i915_gem_object *obj)
> +need_reloc_mappable(struct i915_vma *vma)
> {
> - struct drm_i915_gem_exec_object2 *entry = obj->exec_entry;
> - return entry->relocation_count && !use_cpu
On Fri, Aug 09, 2013 at 10:12:12PM -0700, Ben Widawsky wrote:
> I just noticed in our code we don't really check the assertion, and
> given some of the code I am changing in this area, I feel a WARN is very
> nice to have.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem.c |
On Sat, Aug 10, 2013 at 09:43:48AM +0100, Chris Wilson wrote:
> On Fri, Aug 09, 2013 at 10:12:12PM -0700, Ben Widawsky wrote:
> > I just noticed in our code we don't really check the assertion, and
> > given some of the code I am changing in this area, I feel a WARN is very
> > nice to have.
> >
>
On Fri, Aug 09, 2013 at 10:12:15PM -0700, Ben Widawsky wrote:
> The conditional is usually a recoverable driver bug, and so WARNing, and
> preventing the drm_mm code from doing potential damage (BUG) is
> desirable.
>
> This issue was hit and fixed twice while developing the i915 multiple
> addres
On Fri, Aug 09, 2013 at 10:12:14PM -0700, Ben Widawsky wrote:
> In upcoming code, it will be possible for a vma to have been created,
> but no space reserved for it in the address space. The drm_mm semantics
> are such that trying to remove an unallocated node is not allowed.
But not allocated dur
On Fri, Aug 09, 2013 at 10:12:12PM -0700, Ben Widawsky wrote:
> I just noticed in our code we don't really check the assertion, and
> given some of the code I am changing in this area, I feel a WARN is very
> nice to have.
>
> Signed-off-by: Ben Widawsky
This is BUG() class. A WARN by itself her
On Fri, Aug 09, 2013 at 10:12:13PM -0700, Ben Widawsky wrote:
> Cleanup the map and fenceable setting during bind to make more sense,
> and not check i915_is_ggtt() 2 unnecessary times
>
> Recommended-by: Chris Wilson
> Signed-off-by: Ben Widawsky
There were a couple of bools that only exist to
On Sat, Aug 10, 2013 at 09:55:14AM +0200, Daniel Vetter wrote:
> On Fri, Aug 9, 2013 at 11:34 PM, Paulo Zanoni wrote:
> > 2013/8/9 Chris Wilson :
> >> Quick note...
> >>
> >> On Fri, Aug 09, 2013 at 05:10:05PM -0300, Paulo Zanoni wrote:
> >>> + WARN_ON(!mutex_is_locked(&dev_priv->pc8.lock));
>
On Fri, Aug 9, 2013 at 11:34 PM, Paulo Zanoni wrote:
> 2013/8/9 Chris Wilson :
>> Quick note...
>>
>> On Fri, Aug 09, 2013 at 05:10:05PM -0300, Paulo Zanoni wrote:
>>> + WARN_ON(!mutex_is_locked(&dev_priv->pc8.lock));
>>
>> Preferred form is now lockdep_assert_held(&dev_priv->pc8.lock);
>
> Sh
25 matches
Mail list logo
