On 16-11-24 09:23:31, Jason Ekstrand wrote:
[snip]
Right, you are correct. This is actually a patch from really early days
when I
didn't know any better. We might want to drop this for now, there is the
0/1
color thing for sampler engine that we probably need to fix first
anyway.
Let's drop it if we can.
We should already have code for Broadwell and earlier that prevents
fast-clears with non-0/1 clear colors. We could just also do that on Sky
Lake and deal with partial resolves later. I doubt non-0/1 fast-clear
is a
big enough deal over color compression to slow down getting this landed.
Numbers
What do you mean? Of i recall correctly, we noticed zero speedups in any
apps when we enabled non-0/1 fast clears in the first place. Also, I
wasn't trying to say we shouldn't enable them or shouldn't get them
working; my understanding is that they're enabled and broken today. I was
saying that we shouldn't block landing this on coming up with a partial
resolve story to fix non-0/1 clears with compression because that's really
an unrelated task. We do need better resolves and hopefully we'll get that
done soon but poor Topi has been sitting on this 3‰ perf improvement and
trying to land it fitter months now.
Sorry of that got a bit ranty. I hope it makes more sense.
You made the statement that non 0/1 fast clears are not a big enough deal, and I
was saying I want numbers. We've had benchmarks in the past that we've cared
about which are a big deal.
I realize that we maybe aren't doing things correctly today, but we don't seem
to have failures AFAIK.
Anyway, I'm just asking us to be thorough.
[snip]
--
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
