On 05/04/2015 07:16 AM, Daniel Vetter wrote: > On Thu, Apr 30, 2015 at 12:22:56PM +0100, Chris Wilson wrote: >> On Thu, Apr 30, 2015 at 01:28:46PM +0300, Joonas Lahtinen wrote: >>> On ma, 2015-04-27 at 20:43 +0100, Chris Wilson wrote: >>>> On Mon, Apr 27, 2015 at 06:35:54PM +0100, Thomas Wood wrote: >>>>> On 24 April 2015 at 08:38, Joonas Lahtinen >>>>> <joonas.lahtinen@xxxxxxxxxxxxxxx> wrote: >>>>>> Now that there is PAGE_SIZE define, use it. >>>>> >>>>> Thanks, I've pushed this patch. I also noticed PAGE_SIZE gets defined >>>>> in several tests, so at some point it might be worth moving it into >>>>> the library. >>>> >>>> Be wary of these though. PAGE_SIZE should only ever be used wrt to struct >>>> page and not GPU pages. If you must, please use GTT_PAGE_SIZE instead. >>> >>> Do we have a platform/case where these are different? Just asking out of >>> curiosity :) >> >> Yes. We just haven't enabled big pages yet. The thought of getting globs >> of 64k contiguous physical memory isn't too appealing, but like with >> hugepages there are likely enough tasks that benefit. > > I thought the verdict thus far was that hw engineers overspecced tlbs and > 64k pages aren't really worth it except in some corner-case video code > workloads. Might have changed with the gen8+ pagetables, but I haven't > seen any new noises about this. I hadn't heard that; Damien looked at this awhile back but I'm not sure if he got to the point of getting perf numbers. Those would be nice... there's a lot of added complexity, but if our media processing overhead goes down by 20% it would probably be worth it! Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
