Quoting Tvrtko Ursulin (2017-10-19 11:02:05) > > On 19/10/2017 07:37, Chris Wilson wrote: > > If the device is in runtime suspend, resuming takes time and reduces our > > powersaving. If this was for a small write into an object, that resume > > will take longer than any savings in using the indirect GGTT access to > > avoid the cpu cache. > > Commit talks about small writes but the patch takes no notice to size of > requested writes. Is that intended? We are talking gigabytes before the difference in paths outweigh the worstcase costs, even before we start measuring power. pwrite is a tricky one, for anything big and tiled or for anything where you may repeat the read/write/mmap, you don't want to use pwrite but the direct mmap. pwrite should only wins for small one-off uses, so that's what I have in mind as the typical user -- and I encourage them to re-evaluate their use. So why bother? Because it made a big difference to igt pwrite runtime when we didn't have a display connector. Is the addition in complexity worth it for the few real users? Should we be more aware of the wider implications (both power and performance) of certain operations within the driver? Do we need more mostly idle and/or headless testing? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
