[Mesa-dev] [PATCH 1/7] gallium: add pipe_blend_state::srgb_enable and the CAP

[Jose Fonseca]

On 12/06/17 21:25, Marek Olšák wrote:
> On Mon, Jun 12, 2017 at 9:51 PM, Jose Fonseca <jfonseca at 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