[Intel-gfx] [RFC v2 02/12] drm/i915/svm: Runtime (RT) allocator support

[Chris Wilson]

Quoting Jason Ekstrand (2019-12-14 00:36:19)
> On Fri, Dec 13, 2019 at 5:24 PM Niranjan Vishwanathapura <
> niranjana.vishwanathapura at intel.com> wrote:
> 
>     On Fri, Dec 13, 2019 at 04:58:42PM -0600, Jason Ekstrand wrote:
>     >
>     >     +/**
>     >     + * struct drm_i915_gem_vm_bind
>     >     + *
>     >     + * Bind an object in a vm's page table.
>     >
>     >   First off, this is something I've wanted for a while for Vulkan, it's
>     just
>     >   never made its way high enough up the priority list.  However, it's
>     going
>     >   to have to come one way or another soon.  I'm glad to see kernel API
>     for
>     >   this being proposed.
>     >   I do, however, have a few high-level comments/questions about the API:
>     >    1. In order to be useful for sparse memory support, the API has to go
>     the
>     >   other way around so that it binds a VA range to a range within the BO. 
>     It
>     >   also needs to be able to handle overlapping where two different VA
>     ranges
>     >   may map to the same underlying bytes in the BO.  This likely means that
>     >   unbind needs to also take a VA range and only unbind that range.
>     >    2. If this is going to be useful for managing GL's address space where
>     we
>     >   have lots of BOs, we probably want it to take a list of ranges so we
>     >   aren't making one ioctl for each thing we want to bind.
> 
>     Hi Jason,
> 
>     Yah, some of these requirements came up.
> 
>  
> Yes, I have raised them every single time an API like this has come across my
> e-mail inbox for years and they continue to get ignored.  Why are we landing an
> API that we know isn't the API we want especially when it's pretty obvious
> roughly what the API we want is?  It may be less time in the short term, but
> long-term it means two ioctls and two implementations in i915, IGT tests for
> both code paths, and code in all UMDs to call one or the other depending on
> what kernel you're running on, and we have to maintain all that code going
> forward forever.  Sure, that's a price we pay today for a variety of things but
> that's because they all seemed like the right thing at the time.  Landing the
> wrong API when we know it's the wrong API seems foolish.

Exactly. This is not even close to the uAPI we need. Reposting an RFC
without taking in the concerns last time (or the time before that, or
the time before that...) suggests that you aren't really requesting for
comments at all.
-Chris