On Tue, 2015-05-12 at 23:34 +0200, Roland Scheidegger wrote:
> I like faster!
>
> I don't really understand though where the wins come from.
> softpipe can't have much pending work in the first place (maybe tile
> cache?), llvmpipe potentially has the rasterizer threads I guess but
> I'm not quite sure how this works...
Well the purpose of the series is eliminating the implicit glFlush when
switching contexts, so I think "calling flush way less" is probably the
entirety of the win. There may not be much work to do, but the cost of
figuring that out is non-zero. For softpipe, flushing less mostly
means reducing CPU cycle usage in an entirely cycle-bound execution
path. For llvmpipe I think we're closer to being bound by data cache
throughput than by cycle count, so flushing less is reducing the amount
of redundant d$ work.
The testcase is admittedly pathological, the main loop looks like:
for each window
minor setup
for each span in height
for each window
draw a bit
for each window
swapbuffers
where you have three windows and a height of 100, and every window
switch is a MakeCurrent. So eliminating the flush on ctxsw is
eliminating >300 flushes per frame.
- ajax
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
