All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.