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@xxxxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > > > > > > _______________________________________________ > > amd-gfx mailing list > > amd-gfx@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
