On Sun, 20 Nov 2011 19:09:18 -0800, Ben Widawsky <ben@xxxxxxxxxxxx> wrote: > On Sun, 6 Nov 2011 20:13:48 +0100 > Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > > The gtt_pwrite slowpath grabs the userspace memory with > > get_user_pages. This will not work for non-page backed memory, like a > > gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit > > -EFAULT in the gtt paths. > > > > Now the shmem paths have exactly the same problem, but this way we > > only need to rearrange the code in one write path. > > > > v2: v1 accidentaly falls back to shmem pwrite for phys objects. Fixed. > > > > Signed-Off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > It would be nice if there was some way to notify users that pwriting a > gtt mmapped address can be really damn slow. That's also the one > behavior change this patch introduces. It's possible that some SW was > expecting to get a, "fast path" and would deal with the -EFAULT if it > didn't get it. The behaviour change is intentional. Before this patch we would deadlock... -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
