On Mon, Dec 22, 2014 at 3:20 PM, Chris Forbes <chr...@ijw.co.nz> wrote: > Are there some performance numbers to go with this?
Once of the synmark test cases (terrain) hits this path (pbo upload to a 2d texture array) and the idea is that implementing this avoids the MapTexture fallback paths. The MapTexture paths often end up stalling, doing extra copies or dirtying (setting write domain to cpu) the entire texture even if we only update a part of one slice. As is, the patch series doesn't help that case, since we fail to blit into the texture because it's too big. Bens blitter fix over here: http://cgit.freedesktop.org/~bwidawsk/mesa/log/?h=texture-array-opt works around the limitation by treating each slice as a separate texture and with that I get a 3% speedup on IVB for the mentioned test case. On BYT the speed up is much bigger, since we avoid setting the write domain to cpu for the entire 2d array texture, which avoids clflushing 142mb per batch. I think it might be interesting to try to use meta for blitting instead of the hw blitter. I have a feeling we lose performance in synchronization between the two rings. Kristian > On Tue, Dec 23, 2014 at 12:08 PM, Neil Roberts <n...@linux.intel.com> wrote: >> Here are some patches to make the i965 driver use the blit pipeline >> for sub-texture updates and also for 3D textures and array textures >> (including cube map arrays) when using PBOs. I've also posted some >> patches to update the texsubimage test in Piglit to make sure these >> codepaths are actually tested. >> >> http://cgit.freedesktop.org/piglit/commit/?id=5cfdc9d1d46fce9112845762 >> http://cgit.freedesktop.org/piglit/commit/?id=8433c118dfa6f03f615724d9 >> http://cgit.freedesktop.org/piglit/commit/?id=e4e88dfdb22be7b75150eae4 >> http://lists.freedesktop.org/archives/piglit/2014-December/013814.html >> http://lists.freedesktop.org/archives/piglit/2014-December/013815.html >> http://lists.freedesktop.org/archives/piglit/2014-December/013850.html >> >> I've tested the series with all tests on Piglit on Ivybridge and it >> doesn't cause any regressions. >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
