From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 5/8] drm/i915/context: context validation for execbuffer2 Date: Mon, 14 Feb 2011 21:21:22 +0100 Message-ID: <20110214202122.GA3569@viiv.ffwll.ch> References: <1296687620-27019-1-git-send-email-bwidawsk@gmail.com> <1296687620-27019-6-git-send-email-bwidawsk@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.ffwll.ch (cable-static-49-187.intergga.ch [157.161.49.187]) by gabe.freedesktop.org (Postfix) with ESMTP id C5AB59E732 for ; Mon, 14 Feb 2011 12:21:36 -0800 (PST) Content-Disposition: inline In-Reply-To: <1296687620-27019-6-git-send-email-bwidawsk@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Ben Widawsky Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, Feb 02, 2011 at 03:00:17PM -0800, Ben Widawsky wrote: > Adds the support for actually doing something with buffer validation for > the context when submitted via execbuffer2. When a set of context flags > are submitted in the execbuffer call, the code is able to handle the > commands. It will also go through the existing buffers associated with > the context and make sure they are still present. The big thing missing > is if the client wants to change the domains of buffers which have > already been associated. In this case, the client must disassociate and > then re-associate with the proper domains. Hm, this remark got me thinking (because currently with read/write domains per reloc domain changes on the fly are super-simple): Why not drop the whole associate/disassociate idea and require userspace to always submit a full list of bos still used by this context (and their required offsets)? Upsides: - No fiddling when reused bos change domains. - No need to track stuff in the kernel, we only check the offsets. - Userspace implementation sounds rather straightforward, too: If the aperture check fails, submit the batchbuffer and then store all bos bound to the current gl context (assuming a one-on-one hw context <-> gl context mapping) and their desired domains (also easy because the usage is known). Then on the next execbuffer use that stored array for the additionally required bos (your flag array). - Improvements like ppgtt or (re-)pinning bos at the right place can still be added incrementally. After all, you already require userspace to be able to do a full context restore as part of your abi ... Downsides: - Might no be optimal. But given our constant fiddling with the batchbuffer submission, expecting to get this right on the first try is probably wishful thinking. Just my 2 (constantly changing) cents on this. Anyway, you've thought much more about this than me, so I expect you to shoot this down in a half-sentence ... ;) Yours, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48