On 12/06/17 21:25, Marek Olšák wrote:
On Mon, Jun 12, 2017 at 9:51 PM, Jose Fonseca <jfons...@vmware.com> wrote:
How does this help exactly?
Are applications actually rendering to the same FBO w/ and w/o SRGB
decoding?
Or is the problem here GL_SRGB_WRITE state getting spuriously dirtied by the
application?
And even if they do, why is toggling surface views in framebuffer state so
expensive?
I don't object per se, but it looks like an unusual thing to optimize for.
set_framebuffer_state is basically a memory barrier. We have different
caches between FB and textures and we have to flush them when a
texture is unbound from the framebuffer and set as a sampler view. To
keep thing simple, set_framebuffer_state is the barrier. When we
change the blend state, the barrier is avoided. Note that the barrier
makes set_framebuffer_state a function that is always GPU-bound.
I see.
And you're sure that the incoming set_framebuffer_state are not spurious?
I know cso_context always eliminates redundant
pipe_context::set_framebuffer_state calls, but it is perhaps possible
that Mesa state tracker is reseting the framebuffer state with different
surface views, but that in practice are exactly the same as the previous
one?
Like I said, it seems odd apps are doing this: it doesn't make much
sense to me to change colorspace of the fragments between draws. (Unless
some of the assets are already in SRGB and the app is trying to be too
smart for its own good to avoid the sRGB->RGB->sRGB.) It seems much
more likely that these framebuffer state changes are self-inflicted some
where in our stack, than something truly demanded by the app.
And if that's the case and we can fix it, then it would be a better
solution all around.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
