<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 1:24 PM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <span><br> On 8 April 2015 at 10:57, Vasilis Liaskovitis <<a href="mailto:vliaskov@gmail.com" target="_blank">vliaskov@gmail.com</a>> wrote:<br> > I have an issue where st_TexSubImage causes very high CPU load in<br> > __memcpy_sse2_unaligned (Mesa 10.1.3, Xorg 1.15.1, radeon driver, HD 7870).<br> ><br> > Any obvious causes / tips for this? e.g. align textures or use different<br> > format/type? I 've tried using GL_BGRA/GL_UNSIGNED_BYTE and<br> > GL_BGRA/GL_UNSIGNED_INT_8_8_8_8_REV<br> ><br> > __memcpy_sse2_unaligned () at<br> > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:85<br> > 85 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or<br> > directory.<br> > (gdb) bt<br> > #0 __memcpy_sse2_unaligned () at<br> > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:85<br> > #1 0x00007fffb572f154 in memcpy (__len=7680, __src=<optimized out>,<br> > __dest=0x7fff5835f800) at /usr/include/x86_64-linux-gnu/bits/string3.h:51<br> > #2 st_TexSubImage (ctx=0x1b91420, dims=<optimized out>, texImage=0x1f81710,<br> > xoffset=0, yoffset=0, zoffset=0, width=1920, height=1080, depth=1,<br> > format=32993, type=5121, pixels=0xdacf90, unpack=0x1bad590)<br> > at ../../../../src/mesa/state_tracker/st_cb_texture.c:752<br> <br> </span>Your source (0xdacf90) is only aligned to a 16-byte boundary, not 32.<br> This will cause issues particularly on ARM, where natural alignment is<br> required (i.e. 32-byte load/stores must be on 32-byte boundaries). By<br> contrast, the destination is already aligned to a 128-byte boundary.<br> So fixing the caller, rather than Mesa, should take care of the<br> problem.<br></blockquote><div><br></div><div>thanks for the reply and the observation. I aligned source on 32-byte boundary (or even 128-byte boundary) but there was no difference.<br></div><div>By the way, I am only using x86_64, not ARM. I believe intel sse2 only requires 16-byte boundary alignment, but perhaps i am missing something.<br><br></div><div>Is this code path in <span>st_TexSubImage</span> using PBOs? I guess it depends on driver (radeon in my case) implementation?<br></div><div><br>Related: pboUnpack <a href="http://www.songho.ca/opengl/files/pboUnpack.zip" target="_blank">http://www.songho.ca/opengl/files/pboUnpack.zip</a><br>gives: Transfer Rate: 236.5 MB/s. (59.1 FPS)<br></div><div>Does this sounds reasonably ok for uploading with PBO?<br><br></div><div>Same bottleneck __memcpy_sse2_unaligned is observed.<br></div><div>sample perf report output:<br><br> 28,20% pboUnpack <a href="http://libc-2.19.so" target="_blank">libc-2.19.so</a> [.] __memcpy_sse2_unaligned<br> 16,63% pboUnpack pboUnpack [.] 0x0000000000006542<br> 6,96% pboUnpack [kernel.kallsyms] [k] clear_page_c_e<br> 2,52% pboUnpack [drm] [k] drm_mm_insert_node_in_range_generic<br> 2,10% pboUnpack [kernel.kallsyms] [k] get_page_from_freelist<br><br><br></div><div>backtrace:<br></div><div><br>__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:86<br>86 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.<br>(gdb) bt<br>#0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:86<br>#1 0x00007ffff2bddbbd in memcpy (__len=4194304, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:51<br>#2 memcpy_texture (dimensions=dimensions@entry=2, dstFormat=dstFormat@entry=MESA_FORMAT_B8G8R8A8_UNORM, dstRowStride=dstRowStride@entry=4096, dstSlices=dstSlices@entry=0x7fffffffd6e8, <br> srcWidth=srcWidth@entry=1024, srcHeight=srcHeight@entry=1024, srcDepth=srcDepth@entry=1, srcFormat=srcFormat@entry=32993, srcType=srcType@entry=5121, srcAddr=srcAddr@entry=0x7fffeeecd000, <br> srcPacking=srcPacking@entry=0x7ffff7f69180, ctx=<optimized out>) at ../../../../src/mesa/main/texstore.c:949<br>#3 0x00007ffff2be353d in _mesa_texstore_memcpy (srcPacking=0x7ffff7f69180, srcAddr=<optimized out>, srcType=5121, srcFormat=32993, srcDepth=<optimized out>, srcHeight=<optimized out>, <br> srcWidth=<optimized out>, dstSlices=<optimized out>, dstRowStride=<optimized out>, dstFormat=MESA_FORMAT_B8G8R8A8_UNORM, baseInternalFormat=6408, dims=<optimized out>, ctx=0x7ffff7f4d010)<br> at ../../../../src/mesa/main/texstore.c:3938<br>#4 _mesa_texstore (ctx=0x7ffff7f4d010, dims=2, baseInternalFormat=6408, dstFormat=MESA_FORMAT_B8G8R8A8_UNORM, dstRowStride=4096, dstSlices=0x7fffffffd6e8, srcWidth=1024, srcHeight=1024, srcDepth=1, <br> srcFormat=32993, srcType=5121, srcAddr=0x7fffeeecd000, srcPacking=0x7ffff7f69180) at ../../../../src/mesa/main/texstore.c:3958<br>#5 0x00007ffff2be3812 in store_texsubimage (ctx=ctx@entry=0x7ffff7f4d010, texImage=texImage@entry=0x7c8690, xoffset=xoffset@entry=0, yoffset=yoffset@entry=0, zoffset=zoffset@entry=0, width=1024, <br> height=1024, depth=1, format=32993, type=5121, pixels=0x0, packing=0x7ffff7f69180, caller=0x7ffff2d609c7 "glTexSubImage") at ../../../../src/mesa/main/texstore.c:4107<br>#6 0x00007ffff2be3aa5 in _mesa_store_texsubimage (ctx=ctx@entry=0x7ffff7f4d010, dims=<optimized out>, texImage=texImage@entry=0x7c8690, xoffset=xoffset@entry=0, yoffset=yoffset@entry=0, <br> zoffset=zoffset@entry=0, width=<optimized out>, width@entry=1024, height=<optimized out>, height@entry=1024, depth=<optimized out>, depth@entry=1, format=<optimized out>, format@entry=32993, <br> type=<optimized out>, type@entry=5121, pixels=<optimized out>, pixels@entry=0x0, packing=<optimized out>, packing@entry=0x7ffff7f69180) at ../../../../src/mesa/main/texstore.c:4171<br>#7 0x00007ffff2c3acaa in st_TexSubImage (ctx=0x7ffff7f4d010, dims=<optimized out>, texImage=0x7c8690, xoffset=0, yoffset=0, zoffset=0, width=1024, height=1024, depth=1, format=32993, type=5121, <br> pixels=0x0, unpack=0x7ffff7f69180) at ../../../../src/mesa/state_tracker/st_cb_texture.c:787<br>#8 0x00007ffff2bce83d in texsubimage (ctx=0x7ffff7f4d010, dims=dims@entry=2, target=3553, level=0, xoffset=0, yoffset=0, zoffset=zoffset@entry=0, width=1024, height=1024, depth=depth@entry=1, <br> format=format@entry=32993, type=type@entry=5121, pixels=pixels@entry=0x0) at ../../../../src/mesa/main/teximage.c:3445<br>#9 0x00007ffff2bd259c in _mesa_TexSubImage2D (target=<optimized out>, level=<optimized out>, xoffset=<optimized out>, yoffset=<optimized out>, width=<optimized out>, height=<optimized out>, <br> format=32993, type=5121, pixels=0x0) at ../../../../src/mesa/main/teximage.c:3483<br><br><br></div><div>pixels pointer in st_texSubImage is 0x0 here, maybe because it's an internal pbo to texture transfer? <br></div><div>srcAddr in memcpy_texture() is 0x7fffeeecd000 which looks sufficiently aligned, but maybe this is not the correct pointer to look at.<br><br></div><div>could there also be a CPU stall/sync issue when mapping a pbo buffer?<br><br>Similar pbounpack/memcpy performance discussed a bit here recently with no conclusion: <a href="http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2015-01-01">http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2015-01-01</a><br></div><div><br></div><div>thanks,<br><br></div><div>- Vasilis<br></div><div><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Cheers,<br> Daniel<br> </blockquote></div><br></div></div></div>