From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/4] drm/i915: prevent tiling changes on framebuffer backing storage
Date: Thu, 10 Oct 2013 00:09:48 +0200 [thread overview]
Message-ID: <20131009220948.GT8303@phenom.ffwll.local> (raw)
In-Reply-To: <20131009220217.GS8303@phenom.ffwll.local>
On Thu, Oct 10, 2013 at 12:02:17AM +0200, Daniel Vetter wrote:
> On Wed, Oct 09, 2013 at 10:29:39PM +0100, Chris Wilson wrote:
> > On Wed, Oct 09, 2013 at 09:23:52PM +0200, Daniel Vetter wrote:
> > > Assuming that all framebuffer related metadata is invariant simplifies
> > > our userspace input data checking. And current userspace always first
> > > updates the tiling of an object before creating a framebuffer with it.
> >
> > Userspace already changes the tiling layout whilst keeping the fb id.
>
> How exactly does that work? You can't really change the fb pitch without
> creating a new one ... That leaves switching from tiled to untiled and
> back I think.
Meh, didn't read sna carefully enough. On a second read we only seem to
have the code added
commit 0dd20381364aabede2e1306945abe21d57c1d7b4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Sep 29 11:19:46 2013 +0100
sna: Resize an existing framebuffer if possible
That seems to just be for the cache, should be able to cope with failures
and we can fix it by moving the rmfb up before the set_tiling. It's also
only 2 weeks old.
So if there's nothing else I've missed I strongly vote to break the
pre-release over saner intefaces - allowing tiling to change kinda wreaks
a bit havoc with out in-kernel checks ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2013-10-09 22:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 19:23 [PATCH 0/4] framebuffer_init checks Daniel Vetter
2013-10-09 19:23 ` [PATCH 1/4] drm/i915: grab dev->struct_mutex around framebuffer_init Daniel Vetter
2013-10-09 19:23 ` [PATCH 2/4] drm/i915: prevent tiling changes on framebuffer backing storage Daniel Vetter
2013-10-09 21:29 ` Chris Wilson
2013-10-09 22:02 ` Daniel Vetter
2013-10-09 22:09 ` Daniel Vetter [this message]
2013-10-10 10:53 ` Ville Syrjälä
2013-10-09 19:23 ` [PATCH 3/4] drm/i915: Use unsigned long for obj->user_pin_count Daniel Vetter
2013-10-10 8:56 ` Ville Syrjälä
2013-10-10 8:59 ` Daniel Vetter
2013-10-10 11:29 ` [PATCH] " Daniel Vetter
2013-10-10 11:48 ` Chris Wilson
2013-10-10 12:46 ` Daniel Vetter
2013-10-10 12:48 ` Chris Wilson
2013-10-09 19:23 ` [PATCH 4/4] drm/i915: check gem bo size when creating framebuffers Daniel Vetter
2013-10-09 19:55 ` [PATCH] " Daniel Vetter
2013-10-10 11:42 ` [PATCH 0/4] framebuffer_init checks Ville Syrjälä
2013-10-16 20:08 ` Daniel Vetter
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=20131009220948.GT8303@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox