From mboxrd@z Thu Jan  1 00:00:00 1970
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Subject: Re: [PATCH 2/5] drm/nouveau: add reservation to
	nouveau_gem_ioctl_cpu_prep
Date: Tue, 21 Jan 2014 16:29:22 +0100
Message-ID: <52DE9252.6050007@canonical.com>
References: <1390309482-17313-1-git-send-email-maarten.lankhorst@canonical.com>
	<1390309482-17313-2-git-send-email-maarten.lankhorst@canonical.com>
	<52DE8F98.3020305@vmware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Received: from youngberry.canonical.com (youngberry.canonical.com
	[91.189.89.112])
	by gabe.freedesktop.org (Postfix) with ESMTP id 5FD42FA1FC
	for <dri-devel@lists.freedesktop.org>;
	Tue, 21 Jan 2014 07:29:24 -0800 (PST)
In-Reply-To: <52DE8F98.3020305@vmware.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org

Hey,

op 21-01-14 16:17, Thomas Hellstrom schreef:
> Maarten, for this and the other patches in this series,
>
> I seem to recall we have this discussion before?
> IIRC I stated that reservation was a too heavy-weight lock to hold to
> determine whether a buffer was idle? It's a pretty nasty thing to build in.
>
I've sent this patch after determining that this already didn't end up being heavyweight.
Most places were already using the fence_lock and reservation, I just fixed up the few
places that didn't hold a reservation while waiting. Converting the few places that didn't
ended up being trivial, so I thought I'd submit it.

If a tryreserve fails it's a good indication that the buffer is NOT idle, no need to check the
fences too in that case.

I ended up converting this so I could use shared/exclusive fence slots internally in nouveau,
allowing multiple readers to access the buffers in parallel. See commit
"drm/nouveau: first stab at using shared fences for readable objects" at
http://cgit.freedesktop.org/~mlankhorst/linux/log/

But doing this required killing fence_lock.

~Maarten