On Sat, Aug 10, 2013 at 10:34:29AM +0100, Chris Wilson wrote: > On Sat, Aug 10, 2013 at 11:25:46AM +0200, Daniel Vetter wrote: > > On Thu, Aug 08, 2013 at 02:41:08PM +0100, Chris Wilson wrote: > > > Once again, the CPU PAT bits are irrelevant when considering the GPU > > > cacheing, and context objects are never accessed from the CPU or > > > directly by userspace making them another ideal candidate to allocate > > > from stolen memory. > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > I think this will break hibernate, since over hibernate stolen get some > > garbage. And userspace (and the gpu) probably don't expect garbage when > > trying to restore a hw context. > > Same will be true for framebuffers, which we definitely want to use > stolen for. Suggests we will need to allocate temporaries across > hibernate or warn userspace that the contents are garbage. Yeah, it's not just an issue for contexts but for everything that we don't fully reinit upon wake-up from hibernate. But I have no idea how allocating a temporary shmem node when we do hibernate interferes with the hibernate's page cache shrinker ... Maybe we need to simply clear to black upon resume. The other solution would be to simply give back all the leftover stolen mem to the linux kernel, maybe as a cma block. And teach our allocation functions more smarts to grab hugepages (or cma junks for the fb compressed buffer). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
