| Message ID | 1342160176-1807-3-git-send-email-ben@bwidawsk.net (mailing list archive) |
|---|---|
| State | Deferred |
| Headers | show |
On Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky <ben@bwidawsk.net> wrote: > mostly for convenience, this will help us clear up a bit of the code in > intel_ringbuffer.c I don't think your couple of use-cases is a strong enough argument to justify an extra pointer on thousands of objects. If you wanted, you could make the ilk pc w/a use the status page instead... -Chris
On Fri, 13 Jul 2012 08:47:15 +0100 Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky <ben@bwidawsk.net> wrote: > > mostly for convenience, this will help us clear up a bit of the code in > > intel_ringbuffer.c > > I don't think your couple of use-cases is a strong enough argument to > justify an extra pointer on thousands of objects. > > If you wanted, you could make the ilk pc w/a use the status page > instead... > -Chris > Actually, my original code went a step further than this. It combined all the ring data into 1 object, and then used a mini allocator for the pipe control, ring status, and the few dwords I need. I was _sure_ you would hate that, so I went to this. Can you swallow the one object for everything + allocator idea?
On Fri, 13 Jul 2012 06:56:44 -0700, Ben Widawsky <ben@bwidawsk.net> wrote: > On Fri, 13 Jul 2012 08:47:15 +0100 > Chris Wilson <chris@chris-wilson.co.uk> wrote: > > > On Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky <ben@bwidawsk.net> wrote: > > > mostly for convenience, this will help us clear up a bit of the code in > > > intel_ringbuffer.c > > > > I don't think your couple of use-cases is a strong enough argument to > > justify an extra pointer on thousands of objects. > > > > If you wanted, you could make the ilk pc w/a use the status page > > instead... > > -Chris > > > > Actually, my original code went a step further than this. It combined > all the ring data into 1 object, and then used a mini allocator for the > pipe control, ring status, and the few dwords I need. I was _sure_ you > would hate that, so I went to this. > > Can you swallow the one object for everything + allocator idea? Yes. I'll happily pay a little one-off extra complexity to reduce the number of pages we have allocated for a smattering of dwords. -Chris
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 627fe35..ff0323c 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -988,6 +988,7 @@ struct drm_i915_gem_object { * This is the same as gtt_space->start */ uint32_t gtt_offset; + void *cpu_map; /* optional kernel mapping */ struct intel_ring_buffer *ring; diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 53c3946..c09df96 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3542,6 +3542,9 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj) if (gem_obj->import_attach) drm_prime_gem_destroy(gem_obj, obj->sg_table); + if (WARN_ON(obj->cpu_map)) + kunmap(obj->pages[0]); + if (obj->phys_obj) i915_gem_detach_phys_object(dev, obj);
mostly for convenience, this will help us clear up a bit of the code in intel_ringbuffer.c Signed-off-by: Ben Widawsky <ben@bwidawsk.net> --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 3 +++ 2 files changed, 4 insertions(+)