On 13.02.2012 17:31, Andy Furniss wrote:
Christian König wrote:
A filter strength of zero or one doesn't make any
sense.
Low strengths work OK now, but this patch seems to have made denoise
stronger. Maybe I am looking at the wrong material, but more than 0.2
for sharpen or denoise looks too way much.
Benchmark wise sharpen seems cheap, but denoise at full strength is
expensive, and comparing full on before and after the patch on 1080
material shows that it's doing more work.
Correct, before anything under 0.4 would have given you a zero or one
pixel window and 1.0 would have given you a 9 pixels window, now 0.1
gives you a 3 pixels window (the smallest size that makes sense) and 1.0
gives you an 11 pixels window. Only odd numbers are allowed as window
size, so if 11 is way to strong what would you say is a good maximum for
the window size?
This is with my card (HD4890) on low (239840 kHz) as for htpc it's
quiet, testing a 60 sec stream, roughly -
no options = 16 sec
full sharpen = 24 sec
full denoise before patch = 48 sec
full denoise after patch = 66 sec
Yeah, that was to be expected, for a window size of 3 you need to fetch
5 pixels, for a windows size of 9 you need 17 and for a window size of
11 you need 21...
This is current gits so 2D tiling is on, FWIW vdpau is by far the
biggest gainer from this of anything I've tested - in the past I could
easily compare with R600_TILING= , but I guess I can't turn it off for
textures any more.
That was also to be expected, tilling can dramatically increase the
memory bandwidth, and since we still copy the image data way to often
around with VDPAU it's no wonder that enabling this has a major effect
on that performance. You can still easily disable tilling by just using
an array_mode of zero in r600_texture_create, we have just removed the
environment variable because tilling now seems to work stable.
Christian.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev