[Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects

[Tvrtko Ursulin]

On 05/02/2014 06:15 PM, Ben Widawsky wrote:
> On Fri, May 02, 2014 at 11:27:45AM +0100, Tvrtko Ursulin wrote:
>> Some people expressed interest in tiling so I thought to preserve it in the
>> API.
>>
>> Kernel even allows it, and it is just because Chris found bspec references
>> saying it will break badly on some platforms, that I (or maybe it was both
>> of us) decided to disable it on this level for time being.
>>
>> So I think it is just a matter of coming up with a blacklist and it would be
>> possible to use it then.
>>
>
> Well again, maybe this is specific to my usecase, but I can never
> imagine a use for such fields at this stage in the buffer's lifecycle.
> Could you get "some people" to describe how they want to use it?

Actually thinking about it more, when I collated requirements from 
various groups they were not all that interested. But Chris was actually 
in favour of keeping it in the kernel rather than disabling it 
altogether. So I decided to keep it in the userspace API and only reject 
the attempts to use it for time being.

>>> I think a param for USERPTR is warranted. Or did we decide not to do
>>> this already?
>>
>> I asked for it, but people with authority said no. It is all very weak,
>> fragile and dangerous anyway - param or feature detect like the above.
>>
>> We would really need a proper feature detect mechanism, like text based in
>> sysfs or something.
>>
>
> I don't see why a param is fragile. Feature detect OTOH is almost always
> implemented in a fragile manner.

Not if we had a text file in sysfs with names rather than numbers 
(getparam) without a central allocation authority.

HAS_PARAM(FEATURE1) actually just tricks you into thinking it's fine, 
while actually you are just asking "Do I have feature 48". What is 
feature 48? Who knows... some features never make it to upstream, some 
do and then get their HAS_PARAM number reallocated so it is really weak.

Something like "grep userptr /sys/kernel/debug/dri/0/i915_features", or 
"stat /sys/kernel/debug/dri/0/i915/features/userptr" would be much better.

This way or the other, it seems to be there is not consensus with 
upstream gate keepers whether to have it or not. It was Chris actually 
who ripped it out. Personally I can see both arguments which is why I 
think we should come up with something better.

>>> Probably don't need the special function pointer yet since I don't think
>>> we can yet envision use cases which will require any kind of special
>>> handling. A simple has_userptr in bufmgr_gem will probably suffice. But
>>> I don't care too much either way.
>>
>> What do you mean?
>
> Don't add bo_alloc_userptr to the bufmgr. Just add the prototype to
> intel_bufmgr.h.

Not sure, wouldn't like to make inconsistent.

> I'm pretty close to running this with most of the changes I had asked
> you for. I need to see how much of your igt test I can reuse now.

Cool, so there is nothing for me to do. :)

Regards,

Tvrtko