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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
