[PATCH 4/4] drm/amdkfd: Implement image tiling mode support

[Felix Kuehling]

OK, I was hoping to keep the ABI unchanged during upstreaming, but I
realize that may not be realistic. And I feel I'm getting valuable
feedback, so I don't want to limit myself with ABI requirements that are
not necessary.

I still don't have commit access to git repos on freedesktop.org. But
I'm now planning to upload my WIP to the ROCm repositories on Github as
upstreaming branches for ROCk (kernel) and ROCt (Thunk). I should have
that in place in the next day or two.

If I need to tweak the ABI in the upstreaming process, all I need to
change in user mode is the Thunk, and I can make it available on my
GitHub branch for people to try, regardless of ROCm release schedules.
All the rest of the user mode stack should work unchanged as long as the
Thunk API doesn't need to be changed.

With that in mind, I'll remove the gaps from the ioctl assignment and
accept that KFD will diverge (for the better) from our internal branch
more or less significantly in the upstreaming process.

What's the plan for upstreaming on your side. Do you want to push things
incrementally? Or do you prefer to wait until everything (or most of it)
is reviewed and tested on an upstream-based branch? If it's the latter,
we could reshuffle the ioctls later to better match the current release
ABI before going upstream.

Regards,
  Felix

On 2017-08-14 11:18 AM, Felix Kuehling wrote:
> On 2017-08-13 05:08 AM, Oded Gabbay wrote:
>> As in the previous patch, there is a hole here in the IOCTLs
>> numbering. I suggest that when you upstream new IOCTLs, you will put
>> them in consecutive numbers per the upstream driver, and then take
>> that change downstream because you can easily change it in your
>> driver.
> We can easily change it downstream, but it makes it harder for people to
> test the new upstream kernel with already released ROCm user mode
> drivers that are easy to install and without having to wait a few weeks
> for the next release.
>
> If testability is not a priority, then I'd rather upstream the new
> ioctls in the order in which we made them. The only reason I'm going
> out-of-order is to make testing as easy as possible, as early as
> possible, with the most recently released user mode stack.
>
> It's your call, though.
>
> Regards,
>   Felix
>
>> Oded
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx