Re: [PATCH 2/4] drm/i915: kill obj->gtt_offset

[Chris Wilson <chris@chris-wilson.co.uk>]

On Fri, 15 Apr 2011 21:19:00 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> Mucking around with drm_mm_node->start is a bad idea, it's used to track
> the end of the preceding free area (if there is one).
> 
> Also I find having a bo with a not-page-aligned gtt offset kinda creepy
> ... So if the kernel really needs to track this, could it be tracked in a
> special vmap handle object?

All the relocation handling code is generic: gtt_offset + user delta
Since the gtt_offset is computed once, the vmap code applies the offset to
it directly. I suppose drm_i915_gem_object could grow an additional
gtt_offset_offset...

> Or is this really required, because all the
> normal memory mapper syscalls only work on page boundaries, too. I.e. why
> can't userspace keep track of the offset?

Because that is ugly. Userspace passes in user_addr + user_length which
can be precisely checked for the proposed access.

The alternative you propose is to pass in (user_page_base_addr,
user_page_offset) + user_length and then continue to track
user_page_offset in the userspace code to apply to reloc.delta as well.

In all, I'm favouring keeping gtt_offset. Can we postpone this one until
you've had a chance to review vmap, which I promise will be in the next
set for drm-intel-next-proposed...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre