[Intel-gfx] [PATCH 30/66] drm/i915: Getter/setter for object attributes

[Daniel Vetter]

On Tue, Jul 2, 2013 at 6:51 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> On Tue, Jul 02, 2013 at 09:28:56AM +0200, Daniel Vetter wrote:
>> On Mon, Jul 01, 2013 at 03:59:51PM -0700, Ben Widawsky wrote:
>> > On Mon, Jul 01, 2013 at 09:08:58PM +0200, Daniel Vetter wrote:
>> > > On Mon, Jul 1, 2013 at 8:43 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> > > >> All of this is addressed in future patches. As we've discussed, I think
>> > > >> I'll have to respin it anyway, so I'll name it as such upfront. To me it
>> > > >> felt a little weird to start calling things "ggtt" before I made the
>> > > >> separation.
>> > > >
>> > > > I think now that we know what the end result should (more or less at
>> > > > least) look like we can aim to make it right the first time we touch a
>> > > > piece of code. That will reduce the churn in the patch series and so
>> > > > make the beast easier to review.
>> > > >
>> > > > Imo foreshadowing (to keep consistent with the "a patch series should
>> > > > tell a story" analogy) is perfectly fine, and in many cases helps in
>> > > > understanding the big picture of a large pile of patches.
>> > >
>> > > I've forgotten to add one thing: If you switch these again later on
>> > > (layz me didn't check for that) it's imo best to stick with those
>> > > names (presuming they fit, since the gtt_size vs. obj->size
>> > > disdinction is a rather important one). Again I think now that we know
>> > > where to go to it's best to get there with as few intermediate steps
>> > > as possible.
>> > > -Daniel
>> > >
>> >
>> > I don't recall object size being very important actually, so I don't
>> > think the distinction is too important, but I'm just arguing for the
>> > sake of arguing. With the sg page stuff that Imre did, I think most size
>> > calculations unrelated to gtt size are there anyway, and most of our mm
>> > (not page allocation) code should only ever care about the gtt.
>>
>> The disdinction is only important on gen2/3, which is why you don't recall
>> it being important ;-)
>>
>> I think you have two options:
>> - Trust me that it's indeed important.
>> - Read up on gen2/3 fencing code and make up your own mind.
>>
>> Cheers, Daniel
> I am not saying the distinction doesn't exist. I was saying it's not
> prevalent in too many places. See the second part of my statement, I
> believe it holds.
>
> But please be clear what you're asking for, do you want 2 getters for
> vma size vs. obj size?

I guess we need a few different things:
- vma->node.size: Most functions can probably just access that one
directly (e.g. for writing the ptes), maybe we need something for
transition. I guess we could call it obj_gtt_size since while
transition there's only the one gtt address space.
- The obj size in the gtt. Differs from obj->size on gen2/3 for tiled
objects (and has pretty funny rules at that how it changes). Mostly
important for debugfs, for the gtt stats. Any access helper which just
calls this obj_size is imo highly misleading, hence why I've voted for
for obj_gtt_size.
- I don't think we need an access helper for obj->size itself, since
that is invariant and I don't think we'll move it around either.

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch