On 01/07/15 13:32, Eero Tamminen wrote:
Hi,
On 06/25/2015 04:56 PM, Davin McCall wrote:
On 25/06/15 14:32, Eero Tamminen wrote:
On 06/25/2015 03:53 PM, Davin McCall wrote:
On 25/06/15 12:27, Eero Tamminen wrote:
On 06/25/2015 02:48 AM, Davin McCall wrote:
In terms of performance:
(export LIBGL_ALWAYS_SOFTWARE=1; time glmark2)
For Intel driver, INTEL_NO_HW=1 could be used.
(Do other drivers have something similar?)
Unfortunately I do not have an Intel display set up.
If you can get libINTEL_DEVID_OVERRIDEdrm to use libdrm_intel, you can
fake desired
InteL HW to Mesa with INTEL_DEVID_OVERRIDE environment variable.
Similarly to INTEL_NO_HW, it prevents batches from being submitted
to GPU.
Ok, thanks, I'll look into this shortly. Any pointers on how to get
libdrm to use libdrm_intel?
I think you need to change libdrm code, I don't think there's any
builtin support for that.
I managed to get an Intel-based display set up anyway, and have run some
tests with INTEL_NO_HW=1:
http://lists.freedesktop.org/archives/mesa-dev/2015-June/087410.html
http://lists.freedesktop.org/archives/mesa-dev/2015-June/087808.html
When testing 3D driver CPU side optimizations, one should either use
test specifically written for testing driver CPU overhead (proprietary
benchmarks have such tests) or force test-case to be CPU bound e.g.
with INTEL_NO_HW.
Understood. The 'user' time divided by the glmark2 score should however
give a relative indication of the CPU processing required per frame,
right?
Not necessarily. When CPU isn't fully utilized, it gets downclocked
and getting the speed back up can take some time. This can be pretty
bad for programs that have fairly equal CPU & GPU loads. You really
should select, or make test-case completely CPU bound.
When you want to measure performance impact you want to avoid power
management affecting your results. In worst case you can see improved
performance although you increased CPU load, just because CPU happened
then to run at higher frequency.
I was using the "performance" frequency governor which, as I understand
it, just keeps the CPU frequency pegged to its maximum. Maybe it's more
complicated than that, though. I've run some tests with INTEL_NO_HW=1 as
per links above.
Davin
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
