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

[Marek Olšák]

On Mon, Jun 12, 2017 at 10:43 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> 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.

Yeah the funny part and the reason is that we have a microbenchmark in
piglit (drawoverhead) changing this state between draw calls. :)

Marek