[Intel-gfx] [RFC 00/22] Gen7 batch buffer command parser

[Daniel Vetter]

On Tue, Dec 10, 2013 at 04:58:18PM -0800, Volkin, Bradley D wrote:
> So, I have a functioning kmap_atomic based parser using an sg_mapping_iter, and in the
> tests I'm running, it's worse than the vmap approach. This is still without the batch
> copy, but I think it's relevant anyhow. I haven't done much in the way of analysis as to
> why we're getting these results. At a high level, the vmap approach leads to simple
> code with a few function calls and control structures. The per-page approach has
> somewhat more complex logic around mapping the next page at the right time and checking
> for commands that cross a page boundary. I'd guess that difference factors into it.
>
> Due to the risk of regressions, I think it would be better not to delay getting
> broader functional and performance testing by waiting to sort this out. I'd rather
> stick with vmap for now and revisit that overhead once we have more concrete
> performance data to work from.

Yeah, makes sense. Just to check: Was that on hsw with llc coherency or on
vlv? Might be that the clflushing shifts the picture around a bit.

> I'll propose that I send an updated series later this week or next that addresses
> feedback from the review, including better handling for secure and chained batches,
> the sync fixes for gem_cpu_reloc, some of the additional tests you suggested,
> and possibly an attempt at batch copy. If that goes well, could we see about
> getting the patches into the hands of your QA team for further testing?

We unfortunately don't really have tons of spare cycles from our QA team
for testing branches (pretty much none actually), so the usual approach is
to review and merge patches without first going through QA. If we pull in
your new i-g-ts first we should have decent assurance that nothing blows
up. And since kernel patch series should always be fully bisectable we can
stop at any point in time if something goes wrong.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch