From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: drm/radeon: giving userspace control over hardware engine sync Date: Thu, 14 Aug 2014 14:35:42 -0400 Message-ID: <20140814183542.GF2000@gmail.com> References: <1408032725-6236-1-git-send-email-deathsimple@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by gabe.freedesktop.org (Postfix) with ESMTP id 9CC7B6E733 for ; Thu, 14 Aug 2014 11:35:45 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id l6so1449798qcy.33 for ; Thu, 14 Aug 2014 11:35:45 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1408032725-6236-1-git-send-email-deathsimple@vodafone.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org 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 this bad direction. 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. > 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. In fact i believe getting rid of fence associated to buffer object is what would make sense. 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 clien= ts > etc...) is still implicitly synced to. > = > Patch #4 adds a DONT_FENCE flag that tells the kernel to sync all operati= ons > to a buffer handle, but don't fence that handle with the current command > submission. This is necessarily because we currently abuses zero sized bu= ffer > 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