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

[Oded Gabbay]

On Tue, Aug 15, 2017 at 1:55 AM, Felix Kuehling <felix.kuehling at amd.com> wrote:
> 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 think that's the correct way to go forward.

>
> 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

I prefer to do it incrementally, to avoid very large patch-sets which
usually end up in longer cycles of review-fix, which causes you more
pain because internal development continues during this time and you
need to keep everything synchronized. If you do it in small pieces,
there is more chance it will get to upstream faster and then you can
cross it off your list permanently and no longer worry about it not
being synchronized with internal development.

If you are talking about the current patch-set (you actually sent 2
patch-sets), then once you rebase them on the branches I mentioned,
they are more or less good to go (except from very small fixes we
talked about). If you can do it during this week, I think we can make
it for the 4.14 merge window.

Does that make sense ?

Oded

>
> 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
>