From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Christian_K=F6nig?= Subject: Re: drm/radeon: giving userspace control over hardware engine sync Date: Fri, 15 Aug 2014 14:04:49 +0200 Message-ID: <53EDF761.9090406@vodafone.de> References: <1408032725-6236-1-git-send-email-deathsimple@vodafone.de> <20140814183542.GF2000@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 1271D6E7D3 for ; Fri, 15 Aug 2014 05:05:26 -0700 (PDT) In-Reply-To: <20140814183542.GF2000@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jerome Glisse Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Am 14.08.2014 um 20:35 schrieb Jerome Glisse: > On Thu, Aug 14, 2014 at 06:12:01PM +0200, Christian K=F6nig wrote: >> Hello everyone, >> >> this set of patch adds the ability for userspace to better control when >> synchronization between the different hardware engines on radeon happens. >> Previously every access to a buffer object was serialized and concurrent >> execution could only happen if command submissions didn't shared any >> buffer handle. > I must say i do not like the whole direction of abusing buffer object to = be > expose as fence to userspace. Allowing 0 sized bo was the first step in t= his > bad direction. I'm not very keen about it either, but I wanted to wait what's the final = result of the fence discussion and how we want to expose them to = userspace before switching to something else. > I do understand it's lot easier to implement such things in isolation from > other and that trying to design and get a common kernel subsystem accepted > is way more painful and unpredictible. Correct, comparing the history of GEM named handles and DMA-buf the idea = should be relative clear what we should use. Well after all everything = is just a file, isn't it? >> Patch #1 in this series adds the ability to not only sync before the IB >> execution, but also after it before the fence value is written. This is >> a workaround because TTM currently can't handle multiple fences attached >> to a single buffer object. > We do not want multiple fences to be associated with a buffer object ever. Well maybe we shouldn't use the wording associating the fence to the = buffer, but rather protecting the buffer object by multiple fences. = Otherwise it wouldn't be possible to allow concurrent access from = different hardware engines to the same buffer object. What we should = avoid clearly is exposing any of this to userspace. > In fact i believe getting rid of fence associated to buffer object is what > would make sense. Yeah, agree. We should have a separated fence object that userspace can = query. In the end it should probably be similar to a DMA-buf fd or a = futex. Not sure how a sane interface would look like. Christian. > > Others comment as a per patch reply. > > Cheers, > J=E9r=F4me > >> Patch #2 allows concurrent execution of command submission if there is >> only read only access to the same buffer. >> >> Patch #3 adds a DONT_SYNC flag to each buffer object send to the kernel >> which allows userspace to explicitly note that concurrent access to a >> buffer is ok. The usage of this flag is restricted in that way that each >> operation the client doesn't knows about (eviction, access by other clie= nts >> etc...) is still implicitly synced to. >> >> Patch #4 adds a DONT_FENCE flag that tells the kernel to sync all operat= ions >> to a buffer handle, but don't fence that handle with the current command >> submission. This is necessarily because we currently abuses zero sized b= uffer >> objects as fence handles. >> >> Please review and comment, >> Christian. >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel