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

[Daniel Vetter]

On Wed, Mar 15, 2017 at 01:01:19AM +0100, Marek Olšák wrote:
> While it's nice that you are all having fun here, I don't think that's
> the way to communicate this.
> 
> The truth is, if AMD had an open source driver using the semaphores
> (e.g. Vulkan) and if the libdrm semaphore code was merged, Dave
> wouldn't be able to change it, ever. If a dependent open source
> project relies on some libdrm interface, that interface is set in
> stone. So AMD wouldn't be able to change it either. Unfortunately,
> such an open source project doesn't exist, so the community can assume
> that this libdrm code is still in the "initial design phase". Dave has
> an upper hand here, because he actually has an open source project
> that will use this, while AMD doesn't (yet). However, AMD can still
> negotiate some details here, i.e. do a proper review.

Fully agreed, that's why there was this "internal" qualifier. If you do
this internally, then it's not final, if you discuss it here on the m-l,
it actually matters. So drag your internal teams into the public, and it's
all fine.
-Daniel

> 
> Marek
> 
> 
> On Tue, Mar 14, 2017 at 7:10 PM, Christian König
> <deathsimple at vodafone.de> wrote:
> > 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
> >
> >
> >
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch