On Tue, Jul 10, 2012 at 5:16 PM, Marek Olšák <mar...@gmail.com> wrote: > On Tue, Jul 10, 2012 at 10:00 PM, Jerome Glisse <j.gli...@gmail.com> wrote: >> 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. > > The case where the depth is not reused is the most common one. It > might even be the only one in practice. Depth textures are most > commonly used for shadow mapping, which is the not-reusing case. They > can also be used to implement deferred rendering (though that's not > very common), which means the same as shadow mapping for us. Actually, > no graphics algorithm comes to mind that would do write-texture-write > with the same depth buffer. > > Marek
I am not saying it's not the most common one, i am saying that recompressing might be more complex (recompress to different buffer then copy back to original buffer, or copy buffer and uncompress from copy). Cheers, Jerome _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
