<div dir="ltr">Marek, do you have an idea on where the currency bottleneck is?<div><br></div><div>I just did a profiling with sysprof, zooming in on the desktop in Weston and moving the mouse wildly around, so that the buffer is completely changed for every frame. I got around 5 fps, which isn't *that* much, but still an order of magnitude better than without your patches.</div>
<div><br></div><div>sysprof says there is 100% CPU usage, but unlike the previous 0.5-FPS recording, it's not in a single function, but spread out over several functions:</div><div><br></div><div><div>
<div>35%<span style="white-space:pre-wrap"> </span>weston_recorder_frame_notify</div><div>11%<span style="white-space:pre-wrap"> </span>__memcpy_ssse3</div><div>4.5%<span style="white-space:pre-wrap"> </span>clear_page_c</div>
<div>4.3%<span style="white-space:pre-wrap"> </span>output_run</div></div><div><br></div><div>Although I'm not completely sure I'm reading the sysprof output right. weston_recorder_frame_notify, for example, has 35% CPU usage, but none of its child functions has any significant CPU usage. I presume the CPU usage in that function is from calling <span style="font-size:13.333333015441895px">glReadPixels, although that's not apparent from sysprof:</span></div>
<div><span style="font-size:13.333333015441895px"><br></span></div><div><div><font color="#000000">weston_recorder_frame_notify 39.15% 39.15%</font></div><div>
<font color="#000000"> - - kernel - - 0.00% 0.01%</font></div><div><font color="#000000"> ret_from_intr 0.00% 0.01%</font></div>
<div><font color="#000000"> __irqentry_text_start 0.00% 0.01%</font></div><div><font color="#000000"> irq_exit 0.00% 0.01%</font></div>
<div><font color="#000000"> do_softirq 0.00% 0.01%</font></div><div><font color="#000000"> call_softirq 0.00% 0.01%</font></div>
<div><font color="#000000"> __do_softirq 0.00% 0.01%</font></div><div><font color="#000000"> blk_done_softirq 0.00% 0.01%</font></div>
<div><font color="#000000"> scsi_softirq_done 0.00% 0.01%</font></div><div><font color="#000000"> scsi_finish_command 0.00% 0.01%</font></div>
<div><font color="#000000"> scsi_io_completion 0.00% 0.01%</font></div><div><font color="#000000"> blk_end_request 0.00% 0.01%</font></div>
<div><font color="#000000"> blk_end_bidi_request 0.00% 0.01%</font></div><div><font color="#000000"> blk_update_bidi_request 0.00% 0.01%</font></div>
<div><font color="#000000"> blk_update_request 0.00% 0.01%</font></div><div><font color="#000000"> req_bio_endio.isra.46 0.00% 0.01%</font></div>
<div><font color="#000000"> bio_endio 0.00% 0.01%</font></div><div><font color="#000000"> end_swap_bio_write 0.00% 0.01%</font></div>
<div><font color="#000000"> end_page_writeback 0.00% 0.01%</font></div><div><font color="#000000"> rotate_reclaimable_page 0.01% 0.01%</font></div>
<div><font color="#000000"><br></font></div><div><font color="#000000">Another possible bottleneck is simply disk access, although it doesn't seem to be relevant on my system (since I have 100% CPU usage). The 36-second recording I made was 1.3 GB in size, so that's around 36 MB/s.</font></div>
</div></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><span style="color:rgb(80,0,80)">Med venlig hilsen,</span><br style="color:rgb(80,0,80)"><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">Rune Kjær Svendsen</span><br style="color:rgb(80,0,80)">
<span style="color:rgb(80,0,80)">Østerbrogade 111, 3. - 302</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">2100 København Ø</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">Tlf.: 2835 0726</span><br>
</div></div>
<br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 1:20 AM, Marek Olšák <span dir="ltr"><<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Slowness is not usually a bug.<br>
<br>
I guess it can be optimized even more. It depends on where the<br>
bottleneck is now.<br>
<span class="HOEnZb"><font color="#888888"><br>
Marek<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sun, Mar 17, 2013 at 10:14 PM, Rune Kjær Svendsen<br>
<<a href="mailto:runesvend@gmail.com">runesvend@gmail.com</a>> wrote:<br>
> Thank you very much! This is much better. It's gone from 0.5-ish FPS when<br>
> zooming in to around 10 FPS, depending on screen content.<br>
><br>
> So I figure this isn't a bug? I assumed it was a bug, but is the case simply<br>
> that an efficient glReadPixels path for radeon/gallium doesn't exist?<br>
><br>
> The patch set sure helps in that regard, although it'd be really nice to get<br>
> 30 FPS consistently, if at all possible.<br>
><br>
> Thanks again.<br>
><br>
> /Rune<br>
><br>
><br>
> On Sun, Mar 17, 2013 at 6:46 PM, Andreas Boll <<a href="mailto:andreas.boll.dev@gmail.com">andreas.boll.dev@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 2013/3/17 Rune Kjær Svendsen <<a href="mailto:runesvend@gmail.com">runesvend@gmail.com</a>>:<br>
>> > Hello list<br>
>> ><br>
>> > I'm having problems recording the desktop content using the Weston<br>
>> > compositor's built-in recording function. When I start a recording and<br>
>> > do<br>
>> > something that changes a lot of screen content (like zooming in on the<br>
>> > desktop, for example), I get around 0.5 FPS. Using sysprof, I can see<br>
>> > that<br>
>> > ~98% of CPU is used in the function unpack_XRGB8888(). krh has told me<br>
>> > this<br>
>> > is caused by glReadPixels going through a slowpath. I have a Radeon HD<br>
>> > 5770<br>
>> > GPU and I'm using mesa git (I've tried the mesa version in the Ubuntu<br>
>> > 12.10<br>
>> > repos, and the xorg-edgers PPA, same result).<br>
>> ><br>
>> > Does anyone know what the issue could be, or how to debug the problem<br>
>> > further?<br>
>> ><br>
>><br>
>> This patch series [1] should help. You might want to try it.<br>
>><br>
>> [1] <a href="http://lists.freedesktop.org/archives/mesa-dev/2013-March/036214.html" target="_blank">http://lists.freedesktop.org/archives/mesa-dev/2013-March/036214.html</a><br>
>><br>
>> > Doing some debugging, it seems the call to ctx->Driver.ReadPixels() in<br>
>> > _mesa_ReadnPixelsARB leads to _mesa_readpixels() being called in<br>
>> > readpix.c.<br>
>> ><br>
>> > I'm attaching some output of gdb that will hopefully be useful.<br>
>> ><br>
>> > I'm also attaching the debug terminal output of running Weston with the<br>
>> > DRM<br>
>> > backend.<br>
>> ><br>
>> > Let me know if I can provide other useful information.<br>
>> ><br>
>> > _______________________________________________<br>
>> > mesa-dev mailing list<br>
>> > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
>> > <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
>> ><br>
><br>
><br>
><br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
><br>
</div></div></blockquote></div><br></div>