On Thu, Oct 10, 2013 at 12:09:48AM +0200, Daniel Vetter wrote: > 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@xxxxxxxxxxxxxxxxxx> > 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 ... It would be a bit simpler if we can trust that things don't change after we've created the fb. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
