[PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

Christian König deathsimple at vodafone.de
Tue Mar 14 18:10:15 UTC 2017


Am 14.03.2017 um 18:45 schrieb Harry Wentland:
> On 2017-03-14 06:04 AM, zhoucm1 wrote:
>>
>>
>> On 2017年03月14日 17:20, Christian König wrote:
>>> Am 14.03.2017 um 09:54 schrieb Daniel Vetter:
>>>> On Tue, Mar 14, 2017 at 11:30:40AM +0800, zhoucm1 wrote:
>>>>>
>>>>> On 2017年03月14日 10:52, Dave Airlie wrote:
>>>>>> On 14 March 2017 at 12:00, zhoucm1 <david1.zhou at amd.com> wrote:
>>>>>>> Hi Dave,
>>>>>>>
>>>>>>> Could you tell me why you create your new one patch? I remember I
>>>>>>> send out
>>>>>>> our the whole implementation, Why not directly review our patches?
>>>>>> This is patch review, I'm not sure what you are expecting in 
>>>>>> terms of
>>>>>> direct review.
>>>>>>
>>>>>> The patches you sent out were reviewed by Christian, he stated he
>>>>>> thinks this should
>>>>>> use sync_file, I was interested to see if this was actually 
>>>>>> possible,
>>>>>> so I just adapted
>>>>>> the patches to check if it was possible to avoid adding a lot of amd
>>>>>> specific code
>>>>>> for something that isn't required to be. Hence why I've sent this as
>>>>>> an rfc, as I want
>>>>>> to see if others think using sync_file is a good or bad idea. We may
>>>>>> end up going
>>>>>> back to the non-sync_file based patches if this proves to be a bad
>>>>>> idea, so far it
>>>>>> doesn't look like one.
>>>>>>
>>>>>> I also reviewed the patches and noted it shouldn't add the 
>>>>>> wait/signal
>>>>>> interfaces,
>>>>>> that it should use the chunks on command submission, so while I 
>>>>>> was in
>>>>>> there I re
>>>>>> wrote that as well.
>>>>> Yeah, then I'm ok with this, just our internal team has used this
>>>>> implementation, they find some gaps between yours and previous, they
>>>>> could
>>>>> need to change their's again, they are annoyance for this.
>>>> This is why you _must_ get anything you're doing discussed in upstream
>>>> first. Your internal teams simply do not have design authority on 
>>>> stuff
>>>> like that. And yes it takes forever to get formerly proprietary
>>>> internal-only teams to understand this, speaking from years of
>>>> experience
>>>> implement a proper upstream-design-first approach to feature 
>>>> development
>>>> here at intel.
>>>
>>> "internal teams simply do not have design authority on stuff like that"
>>>
>>> Can I print that on a t-shirt and start to sell it?
>> I guess you cannot dress it to go to office..:)
>>
>
> I'd wear it to the office.
>
> https://www.customink.com/lab?cid=hkp0-00ay-6vjg

I'm only at an AMD office every few years, so that's probably not worth it.

Anyway it's really something we should keep in mind if we want to 
upstream things.

Christian.

>
> Harry
>
>> David Zhou
>>>
>>> Christian.
>>>
>>>> -Daniel
>>>
>>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx




More information about the amd-gfx mailing list