On Thu, Apr 6, 2017 at 12:49 PM, Thomas Helland <thomashellan...@gmail.com> wrote: > This series has been reciding on my computer for way to long, > so it's about time I get it out there for some feedback. > The rationale is that in the glsl compiler a lot of the overhead > is in cache misses due to the visitor pattern we're running.
perf can measure various kinds of cache misses. It would be good to confirm your hypothesis. > This is run on my intel machine. > > Here are some perf stat results before and after the series > on a shader-db run on a subset of my shader-db. > > Before: > 56 849 919 924 cycles:u # 2,894 GHz > 21 803 529 990 stalled-cycles-frontend:u # 38,35% frontend cycles idle > 82 463 039 717 instructions:u # 1,45 insn per cycle > # 0,26 stalled cycles per insn > 16 796 501 647 branches:u # 855,182 M/sec > 394 313 169 branch-misses:u # 2,35% of all branches > > 20,568256999 seconds time elapsed > > > After: > 55 956 131 481 cycles:u # 2,884 GHz > 21 889 872 343 stalled-cycles-frontend:u # 39,12% frontend cycles idle > 80 666 584 607 instructions:u # 1,44 insn per cycle > # 0,27 stalled cycles per insn > 16 349 063 938 branches:u # 842,630 M/sec > 383 226 870 branch-misses:u # 2,34% of all branches > > 20,342067729 seconds time elapsed > > So, some things to notice: > There's a decent drop in executed instructions. > There's an increase in stalled cycles, which is not what I expected. > We are still seeing an ever so slight reduction in runtime. > Fewer branches, and fewer branch-prediction misses. > > The question is if this is a route we want to go down? I think so! From a quick glance the series looks nice. I'll review in more depth soon. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
