On Wed, Jun 11, 2014 at 02:40:00PM +0300, Ville Syrjälä wrote: > On Wed, Jun 11, 2014 at 11:28:41AM +0100, Chris Wilson wrote: > > Currently objects for which the hardware needs a contiguous physical > > address are allocated a shadow backing storage to satisfy the contraint. > > This shadow buffer is not wired into the normal obj->pages and so the > > physical object is incoherent with accesses via the GPU, GTT and CPU. By > > setting up the appropriate scatter-gather table, we can allow userspace > > to access the physical object via either a GTT mmaping of or by rendering > > into the GEM bo. However, keeping the CPU mmap of the shmemfs backing > > storage coherent with the contiguous shadow is not yet possible. > > Fortuituously, CPU mmaps of objects requiring physical addresses are not > > expected to be coherent anyway. > > > > This allows the physical constraint of the GEM object to be transparent > > to userspace and allow it to efficiently render into or update them via > > the GTT and GPU. > > > > v2: Fix leak of pci handle spotted by Ville > > v3: Remove the now duplicate call to detach_phys_object during free. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Looks good. pread and cpu mmap would get garbage but that's nothing > new, and commit message says as much. > > phys pread should be rather easy to add (not much different from > i915_gem_phys_pwrite()), but I guess no one has needed it since > it's not there. For completeness, we should do it. But as you say, no one has yet requested the bits back from the phys object, and now if they really do desire they can at least use a GTT mmap. > Oh, should there be a i915_gem_object_wait_rendering() in phys pwrite? Yes. > But in any case this patch is: > Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> I'll add the wait. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx