On Tue, Mar 14, 2017 at 02:16:11PM +1000, Dave Airlie wrote: > On 14 March 2017 at 13:30, zhoucm1 <david1.zhou@xxxxxxx> 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 unfortunate, but the more internal development done, the more > this will happen, > especially in areas where you might interact with the kernel. I'd > suggest trying to > develop stuff in the open much earlier (don't start anything in-house). > > Now that we have an open vulkan driver it might be that most features > the internal > vulkan driver requires will eventually be wanted by us, Yeah that's another aspect, radv is the open vulkan driver for amd hw, which means it gets to drive uapi. -Daniel -- 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
