[Intel-gfx] [PATCH 3/6] drm/i915: Add support for stealing purgable stolen pages

[Gupta, Sourab]

On Wed, 2014-04-09 at 13:06 +0000, Daniel Vetter wrote:
> On Tue, Apr 08, 2014 at 06:53:03AM +0000, Gupta, Sourab wrote:
> > On Tue, 2014-04-08 at 06:45 +0000, Chris Wilson wrote:
> > > On Tue, Apr 08, 2014 at 04:32:02AM +0000, Gupta, Sourab wrote:
> > > > Hi Rodrigo,
> > > > In this patch, while freeing the purgeable stolen object, the memory
> > > > node also has to be freed, so as to make space for new object. We need
> > > > to call drm_mm_remove_node while freeing obj.
> > > > 
> > > > The below modification patch was floated earlier for this purpose:
> > > > http://lists.freedesktop.org/archives/intel-gfx/2014-March/041282.html
> > > 
> > > Right, I have a v2 locally with the fix you identified.
> > > -Chris
> > > 
> > Ok, Thanks Chris.
> 
> I'd really prefer if someone would pick up all the
> stolen/create2_ioctl/whatever patches, pack them up into a polished
> series, add the testcases and submit this all for review and merging.
> 
> Otherwise this will linger forever and we'll get nowhere. Chris seems
> swamped with other stuff, so Sourab could you please take a look at this?
> 
> Please check with your manager that you have sufficient bandwidth to pull
> this through.
> 

I'll be on vacation from next week, so I'll be able to gauge this better
after coming back.
Nevertheless, I have some questions regarding the expectation of
userspace code changes required for these patches (i.e. libdrm changes
and igt testcases)

1) For libdrm , I am assuming, a counterpart of
drm_intel_gem_bo_alloc_tiled() function would call the create2 ioctl and
take in the parameters needed. 
Should the caching of objects from libdrm need to take care of both the
placement domains seperately (as in different sets of bo buckets)?
Should libdrm be transparent to all the combinations of different
parameters being passed by user or should the prohibited combinations be
disallowed from libdrm side?

2) For the igt, since we have a lot of parameters exposed to user, the
number of subtests required may be huge and still they may not test out
everything. 
So, Is the expectation here to have exhaustive test cases for all the
parameters (tiling/cache/domain/madvise/offset etc.) going in as input
to the create2 ioctl?
For eg. let us say we are going to check the render copy operation of
src and dest bo's. Do we need to provide all possible combinations of
different (create2 ioctl) input parameters to these src and dest bo's
and then run the render copy test for all these combinations.
Any guiding pointers from your side as to how we may go about the igt
testcases?

Thanks,
sourab

> Rodrigo, I think you can drop this patch from -collector, it only really
> makes sense in the context of all the other stolen work.
> 
> Thanks, Daniel