From: Lauri Kasanen <cand@gmx.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: Required backwards support level?
Date: Mon, 7 Apr 2014 10:28:33 +0300 [thread overview]
Message-ID: <20140407102833.8b805fbf.cand@gmx.com> (raw)
In-Reply-To: <CAKMK7uFvi3Pyv+gcJzrCf9LJ+W9FTwGOAF1r=k72v0j=-RUmtQ@mail.gmail.com>
On Sun, 6 Apr 2014 19:58:48 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen <cand@gmx.com> 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
next prev parent reply other threads:[~2014-04-07 7:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-06 12:26 Required backwards support level? Lauri Kasanen
2014-04-06 14:53 ` Rob Clark
2014-04-06 17:28 ` Lauri Kasanen
2014-04-06 17:58 ` Daniel Vetter
2014-04-07 7:28 ` Lauri Kasanen [this message]
2014-04-07 2:26 ` Michel Dänzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140407102833.8b805fbf.cand@gmx.com \
--to=cand@gmx.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.