From: Lauri Kasanen <cand@gmx.com>
To: Rob Clark <robdclark@gmail.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: Required backwards support level?
Date: Sun, 6 Apr 2014 20:28:59 +0300 [thread overview]
Message-ID: <20140406202859.37538e55.cand@gmx.com> (raw)
In-Reply-To: <CAF6AEGvO3znWNJmTjygF8BcaMMKbyBsFXuY0sW+0K19uXQwnvw@mail.gmail.com>
On Sun, 6 Apr 2014 10:53:58 -0400
Rob Clark <robdclark@gmail.com> wrote:
> On Sun, Apr 6, 2014 at 8:26 AM, Lauri Kasanen <cand@gmx.com> wrote:
> > Hi,
> >
> > Obviously old userspace + new kernel combo needs to be supported. But
> > I'm not so sure about a mixed case, does old userspace + new userspace
> > need to be supported to run at the same time?
> >
> > For example, a new 64-bit mesa+libdrm and a 32-bit old set, both
> > running apps at the same time.
> >
> > Or is it acceptable to assume that once a new userspace has been run,
> > an old one won't be run for this boot?
>
> old 32b userspace in a chroot, for example?
Yes, for example.
> Maybe you can give a better description of what you are wanting to do?
> Could you decide on 32b vs 64b userspace on a per 'struct drm_file'
> basis (ie. each time /dev/dri/cardN is opened)?
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.
- Lauri
next prev parent reply other threads:[~2014-04-06 17: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 [this message]
2014-04-06 17:58 ` Daniel Vetter
2014-04-07 7:28 ` Lauri Kasanen
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=20140406202859.37538e55.cand@gmx.com \
--to=cand@gmx.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=robdclark@gmail.com \
/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.