On Tue, Jul 10, 2012 at 2:10 PM, Marek Olšák <mar...@gmail.com> wrote: > On Tue, Jul 10, 2012 at 6:40 AM, Vadim Girlin <vadimgir...@gmail.com> wrote: >> On Sat, 2012-07-07 at 01:48 +0200, Marek Olšák wrote: >>> On Wed, Jun 27, 2012 at 1:34 AM, Vadim Girlin <vadimgir...@gmail.com> wrote: >>> > Use r600_resource_texture::flished_depth_texture for GPU access, and >>> > allocate it in the VRAM. For transfers we'll allocate untiled texture in >>> > the >>> > GTT and store it in the r600_transfer::staging. >>> > >>> > Improves performance when flushed depth texture is frequently used by the >>> > GPU (about 30% for Lightsmark). >>> > >>> > Signed-off-by: Vadim Girlin <vadimgir...@gmail.com> >>> > --- >>> > >>> > Fixes fbo-clear-formats, fbo-generatemipmap-formats, no regressions on >>> > evergreen >>> >>> Hi, >>> >>> is there any reason this patch hasn't been committed yet? >>> >> >> Hi, >> >> I have some doubts because it was benchmarked by phoronix and there were >> regressions, though I suspect that something is wrong with the results: >> >> http://www.phoronix.com/scan.php?page=article&item=amd_r600g_texdepth&num=4 >> >> I was going to look into it but had no time yet. I'd like to be sure >> that there are no regressions before committing. > > Well, there's nothing wrong with your patch. I wouldn't trust > benchmarks run with the Unity desktop so much. I myself had to switch > from Unity 2D to Xfce just to get consistent results when testing > performance. > > Now that your patch separates flushing for texturing and transfers, I > think we could make it a little bit faster by imlementing an in-place > flush for texturing (that is without having to allocate another > resource). > > Marek
In place flush are useful for the case where you know you wont reuse the depth buffer as a depth buffer, or if you know next operation will be a gClear on the depth buffer. What i am worried about is that recompression might not work in place, for it to work you need to have db decompressed into db tiling format and not cb tiling format. Cheers, Jerome _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
