On Wed, Jun 11, 2014 at 02:17:21PM -0700, Volkin, Bradley D wrote: > On Tue, Jun 10, 2014 at 04:14:41AM -0700, Chris Wilson wrote: > > On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences, using i-g-t/gem_fence_upload: > > Upload rate for 2 linear surfaces: 8134MiB/s -> 8154MiB/s > > Upload rate for 2 tiled surfaces: 8625MiB/s -> 8632MiB/s > > Upload rate for 4 linear surfaces: 8127MiB/s -> 8134MiB/s > > Upload rate for 4 tiled surfaces: 8602MiB/s -> 8629MiB/s > > Upload rate for 8 linear surfaces: 8124MiB/s -> 8137MiB/s > > Upload rate for 8 tiled surfaces: 8603MiB/s -> 8624MiB/s > > Upload rate for 16 linear surfaces: 8123MiB/s -> 8128MiB/s > > Upload rate for 16 tiled surfaces: 8606MiB/s -> 8618MiB/s > > Upload rate for 32 linear surfaces: 8121MiB/s -> 8128MiB/s > > Upload rate for 32 tiled surfaces: 8605MiB/s -> 8614MiB/s > > Upload rate for 64 linear surfaces: 8121MiB/s -> 8127MiB/s > > Upload rate for 64 tiled surfaces: 3017MiB/s -> 5127MiB/s > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Testcase: i-g-t/gem_fence_upload > The translation from vm_insert_pfn to remap_pfn_range looks correct. I don't know > these APIs particularly well though. I wonder if there's any reason it would be > unsafe to call remap_pfn_range from .fault() since it seems to only be used in > .mmap() handlers in other places. Reading their implementations, nothing jumped > out, so I'll say Right, using it within the fault handler is fine. The underlying operations are equivalent to the vm_insert_pfn() just unrolled for a contiguous range. So the reason why other drivers do it in their mmap handler rather than at fault is that they have a radically simpler driver model than we do. An exercise for the reader would be to erradicate the walk_system_ram() still required by remap_pfn_range() which we avoided in our prototypical vm_insert_pfn_from_io_mapping(). [We could simply do a remap_pfn_from_io_mapping that shared the core with remap_pfn_range I guess.] -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
