On 05/19/2015 04:46 PM, Adam Jackson wrote:
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
Thanks for the explanation, makes sense. So real world gains probably
unfortunately won't be anywhere close unless someone is really doing
something weird, but every little bit helps...
So,
Acked-by: Roland Scheidegger <srol...@vmware.com>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
