<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 15, 2013 at 3:19 PM, José Fonseca <span dir="ltr"><<a href="mailto:jose.r.fonseca@gmail.com" target="_blank">jose.r.fonseca@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Thanks for the figures. They sound good.</div>
<div><br></div><div>I finally started testing this.</div><div><br></div><div>I noticed one problem though -- the handling of exceptions: it is imperative that when there is a crash inside a GL call, all pending calls up to the crash get written to the trace file. But this is not happening with threaded-file branch.</div>
<div><br></div><div>I made a test for this, at <a href="https://github.com/apitrace/apitrace-tests/commit/c8219f827e6aa4dcad2e94c6b05976b58c266ddc" target="_blank">https://github.com/apitrace/apitrace-tests/commit/c8219f827e6aa4dcad2e94c6b05976b58c266ddc</a> , and tracing it should produce something like</div>
<div><br></div><div><div><font face="courier new, monospace"> $ apitrace dump -v exception.trace</font></div><div><font face="courier new, monospace"> [...]</font></div><div><font face="courier new, monospace"> 11 glGetIntegerv(pname = GL_VIEWPORT, params = ?) // incomplete</font></div>
<div><br></div><div><br></div><div>Commit "Support for threaded compession" introduces abstractions for platform-specific thread functions which duplicate the existing ones. Please rewrite the code to use the existing abstractions, which are based off <a href="http://en.cppreference.com/w/cpp/thread/thread" target="_blank">http://en.cppreference.com/w/cpp/thread/thread</a> .</div>
<div><br></div><div>I believe we can proceed with LZ4 format however. </div></div></div></blockquote><div><br></div><div style>One request concerning LZ4: please refactor the code such that trace_file.hpp doesn't include snappy.h, lz4.h, lz4hc.h , zlib.h . This file is included in several source files, so it should contain only the interface, not actually any compression-specific implementation details.</div>
<div style><br></div><div style>The hope is that in the future the wrapper libraries won't need to statically link against all these libraries, but only one (the best). The other tools can link against all of them for backwards compatibility, but they can dynamically link.</div>
<div> </div><div style>Jose</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><div><br></div><div>Jose</div></div><div class="im"><div><br></div>On Tue, Jun 4, 2013 at 9:14 PM, Eugene Velesevich <span dir="ltr"><<a href="mailto:eugvelesevich@gmail.com" target="_blank">eugvelesevich@gmail.com</a>></span> wrote:<br>
</div><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The best improvements we've seen were on an arm/android board, where<br>
the threaded approach eliminated very noticeable periodic stutters<br>
from compression; however, it's hard to provide quantitative data on<br>
that. On a modern x86 system, we're seeing 7-8% better fps rates with<br>
ipers, even with lz4hc compression that consumes 30-40% cpu in its<br>
thread.<br>
<br>
With regards to compression ratio the LZ4 compressed trace of ipers is<br>
larger by 11-12% than the snappy one, but LZ4HC compresses better by<br>
35-36% than snappy (you can check it using "apitrace repack")<br>
<div><div><br>
On Sun, Jun 2, 2013 at 5:09 PM, José Fonseca <<a href="mailto:jose.r.fonseca@gmail.com" target="_blank">jose.r.fonseca@gmail.com</a>> wrote:<br>
> I haven't looked at the changes in detail yet -- I'll do it as soon as I<br>
> find the time -- but sounds good in principle. Indeed trying out LZ4 has<br>
> been in the to do for some time, so thanks for doing this.<br>
><br>
> Did you get any figures (speed r& compression ratio) on how it compares with<br>
> snappy? A good benchmark is "ipers" demo, part of mesa demos. It is what<br>
> Zack used when he was improving the compression speed w/ snappy.<br>
><br>
> Jose<br>
><br>
><br>
><br>
> On Sat, Jun 1, 2013 at 2:39 PM, evel <<a href="mailto:evel@ispras.ru" target="_blank">evel@ispras.ru</a>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> This patch series improves trace compression by implementing threaded<br>
>> compression offloading and providing alternative compression methods. The<br>
>> main difference from previously implemented threaded compression is that<br>
>> locking overhead is significantly reduced thanks to using a<br>
>> double-buffered<br>
>> output buffer instead of a ring buffer that was locked on each call dump<br>
>> operation.<br>
>><br>
>> <a href="https://github.com/Testiki/apitrace/tree/threaded-file" target="_blank">https://github.com/Testiki/apitrace/tree/threaded-file</a><br>
>> _______________________________________________<br>
>> apitrace mailing list<br>
>> <a href="mailto:apitrace@lists.freedesktop.org" target="_blank">apitrace@lists.freedesktop.org</a><br>
>> <a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> apitrace mailing list<br>
> <a href="mailto:apitrace@lists.freedesktop.org" target="_blank">apitrace@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
><br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>