From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?q?Christian=20K=C3=B6nig?= Subject: drm/radeon: giving userspace control over hardware engine sync Date: Thu, 14 Aug 2014 18:12:01 +0200 Message-ID: <1408032725-6236-1-git-send-email-deathsimple@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 64D4F6E6EB for ; Thu, 14 Aug 2014 09:14:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by pegasos-out.vodafone.de (Rohrpostix2 Daemon) with ESMTP id D5E9072A136 for ; Thu, 14 Aug 2014 18:14:39 +0200 (CEST) Received: from pegasos-out.vodafone.de ([127.0.0.1]) by localhost (rohrpostix2.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulPVFbKKMhB5 for ; Thu, 14 Aug 2014 18:14:18 +0200 (CEST) Received: from smtp-02.vodafone.de (smtp-02.vodafone.de [10.215.254.37]) by pegasos-out.vodafone.de (Rohrpostix2 Daemon) with ESMTP id AFB7D72A133 for ; Thu, 14 Aug 2014 18:12:22 +0200 (CEST) Received: from smtp-02.vodafone.de ([127.0.0.1]) by localhost (xsmail-dmz6.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZf3L8CP1cD6 for ; Thu, 14 Aug 2014 18:12:08 +0200 (CEST) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org 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. 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. 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 clients etc...) is still implicitly synced to. Patch #4 adds a DONT_FENCE flag that tells the kernel to sync all operations to a buffer handle, but don't fence that handle with the current command submission. This is necessarily because we currently abuses zero sized buffer objects as fence handles. Please review and comment, Christian.