Am 15.03.2017 um 09:48 schrieb 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.
Unfortunately it's not done with that. You also need to raise company
wide awareness of changed needs.
For example the concept that changes aren't allowed to break older
upstream components is completely new to most teams inside AMD.
It's a rather painful learning curve when you want to move projects from
closed source to open source.
Christian.
-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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
