<div dir="ltr"><div style>Thanks for the figures. They sound good.</div><div style><br></div><div style>I finally started testing this.</div><div><br></div><div style>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 style><br></div><div style>I made a test for this, at <a href="https://github.com/apitrace/apitrace-tests/commit/c8219f827e6aa4dcad2e94c6b05976b58c266ddc">https://github.com/apitrace/apitrace-tests/commit/c8219f827e6aa4dcad2e94c6b05976b58c266ddc</a> , and tracing it should produce something like</div>
<div style><br></div><div style><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 style>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">http://en.cppreference.com/w/cpp/thread/thread</a> .</div>
<div><br></div><div style>I believe we can proceed with LZ4 format however. </div><div><br></div><div style>Jose</div></div><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 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 class=""><div class="h5"><br>
On Sun, Jun 2, 2013 at 5:09 PM, José Fonseca <<a href="mailto:jose.r.fonseca@gmail.com">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">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">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">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>