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. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
