From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lauri Kasanen Subject: Re: Required backwards support level? Date: Mon, 7 Apr 2014 10:28:33 +0300 Message-ID: <20140407102833.8b805fbf.cand@gmx.com> References: <20140406152616.a7b22a4e.cand@gmx.com> <20140406202859.37538e55.cand@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by gabe.freedesktop.org (Postfix) with ESMTP id 2FD9A6E51B for ; Mon, 7 Apr 2014 00:28:07 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Sun, 6 Apr 2014 19:58:48 +0200 Daniel Vetter wrote: > On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen wrote: > > This is related to my memory management work. As the VRAM queue is > > global, it cannot be determined on a per-app basis. If at least one > > client is running old userspace, the new scoring cannot be used. > > > > Switching live between the two would bring additional complexity. I'd > > hope to be able to determine by the first 3d app if the userspace is > > new enough. But that depends on if it's expected to be able to run > > mixed loads. > > At least thus far we've worked under the example that any > explicitly-enabled new behaviour is only enabled per-fd. That's also > useful when you install all your developer versions into a prefix, so > still have 2 versions of X driver, libdrm, mesa, everything else lying > around and want to switch at runtime even. > > Can't you fake a default score somehow for all legacy userspace and > always run with the new code? Reimplementing the old interfaces in > terms of the new ones also allows you to kick out duplicated code > (usually) compared to having both old and new code around. Certainly, that can be done. - Lauri