On 03/26/2013 06:26 PM Rune Kjær Svendsen wrote:
(I'm re-sending this message because the attachment was too large for
mesa-dev, and because I want to add wayland-devel CC. The valgrind output
can be found here: http://runeks.dk/files/callgrind.out.11362).
Seems like you are right Pekka.
I just ran weston through valgrind, and got some interesting results. I ran
it like so:
valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes weston
Which allows me to get the time spent on a per-instruction level. Now, this
is running inside a virtual machine, so it won't be the same as running it
natively, but it agrees with the other benchmarks in the sense that it
suggests it is the simple calculations inside screenshooter.c that take up
most of the CPU time, not calls to outside functions (like it was before
with the slow glReadPixels() path).
The callgrind output can be found at the following URL:
http://runeks.dk/files/callgrind.out.11362
Open it with KCachegrind, select the function
weston_recorder_frame_notify(), and go to the "Machine Code" tab in the
lower right corner to see the interesting stuff.
According to callgrind, a total of 54.39% CPU time is used in the four
lines 251, 252, 253 and 255 in screenshooter.c. That's the function
component_delta():
dr = (next>> 16) - (prev>> 16);
dg = (next>> 8) - (prev>> 8);
db = (next>> 0) - (prev>> 0);
return (dr<< 16) | (dg<< 8) | (db<< 0);
Better double check (since I did this from old memories of bit-diddling ;-)
but I think this does the same, just a bit faster (with -O2 reduces time
vs the above by about 44% in my QND test):
uint32_t
component_delta2(uint32_t next, uint32_t prev)
{
return ((((next&0xff00ff)-(prev&0xff00ff)+0x100)&0xff00ff)+
(((next&0xff00)-(prev&0xff00))&0xff00));
}
Regards,
Bengt Richter
(Note that I appended '2' to the name for testing).
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
