On 19/10/2017 11:19, Chris Wilson wrote:
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
No real complaints, just read the commit and expected to see something
about the size in the patch itself.
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?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
