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

[Jose Fonseca]

On 14/06/17 22:16, Brian Paul wrote:
> On 06/14/2017 02:38 PM, Jose Fonseca wrote:
>> On 14/06/17 21:21, Marek Olšák wrote:
>>> On Wed, Jun 14, 2017 at 10:13 PM, Jose Fonseca <jfonseca at vmware.com>
>>> wrote:
>>>> On 14/06/17 21:07, Marek Olšák wrote:
>>>>>
>>>>> On Wed, Jun 14, 2017 at 9:45 PM, Jose Fonseca <jfonseca at vmware.com>
>>>>> wrote:
>>>>>>
>>>>>> On 14/06/17 17:12, Marek Olšák wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 13, 2017 at 3:43 PM, Marek Olšák <maraeo at gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 13, 2017 at 1:40 PM, Jose Fonseca <jfonseca at vmware.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/06/17 22:56, Marek Olšák wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I couldn't find that piglit microbenchmark.  mesademos has
>>>>>>>>> src/perf/drawoverhead.c but it doesn't set GL_SRGB_WRITE.  So if
>>>>>>>>> fbo
>>>>>>>>> is
>>>>>>>>> changing internally, then it's a perf bug in Mesa state tracker.
>>>>>>>>>
>>>>>>>>> Unless it's mimicking something that real apps do, then it's
>>>>>>>>> probably
>>>>>>>>> better
>>>>>>>>> to fix the microbenchmark to use a more realistic tests.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If you build piglit, it's in bin/drawoverhead.
>>>>>>>>
>>>>>>>> You're right that this subtest (switching GL_FRAMEBUFFER_SRGB) is
>>>>>>>> rather artificial and fairly unlikely to occur with real apps.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> FYI, I'm dropping this series and I don't have it in my repo 
>>>>>>> anymore.
>>>>>>> piglit/drawoverhead will be updated not to test this state change.
>>>>>>>
>>>>>>> Marek
>>>>>>
>>>>>>
>>>>>>
>>>>>> Great.
>>>>>>
>>>>>> BTW, I'm not sure what's a good state to change in such
>>>>>> microbenchmark.
>>>>>>
>>>>>> There is of course, a myriad of states to pick, but they are not
>>>>>> all the
>>>>>> same: performance can vary wildly depending on the choice.   I'm
>>>>>> not sure
>>>>>> what's a good representative state change in such circumstances
>>>>>> Perhaps
>>>>>> toggling between two texture objects? Or some sampler state?
>>>>>
>>>>>
>>>>> If you've ever run the microbenchmark, you know there are plenty of
>>>>> state changes tested. I think there are like 15 state changes tested
>>>>> in about 60 subtests at the moment. I'm adding more tests into it.
>>>>> Currently I have 100 subtests in there locally. At the moment the
>>>>> missing subtests are mostly just shader resources: immutable textures
>>>>> (mutable textures i.e. not TexStorage-based are already tested), TBOs,
>>>>> images, image buffers, SSBOs (maybe), atomic counters (maybe). The
>>>>> methodology is 1 state change followed by 1 draw call in a loop,
>>>>> measuring the number of draw calls per second for that case, and
>>>>> comparing with the baseline draw rate (which is without the state
>>>>> change).
>>>>>
>>>>> Marek
>>>>>
>>>>
>>>> I just ran it.  Pretty neat!  I didn't know we were adding 
>>>> benchmarks to
>>>> piglit.
>>>
>>> That's because piglit has a very convenient window system integration
>>> framework that I refuse to re-invent elsewhere.
>>
>> Ah, makes sense.
>>
>>
>> Which reminds me: do people think we should transition mesademos off
>> glut to glfw or waffle? Or do you think we should just strive to migrate
>> the stuff there to piglit?
> 
> I'm not sure I see a need.  Does anyone use the Mesa demos for 
> benchmarking anymore?

I wasn't thinking of benchmarking per se, but just being able to run any 
of the Mesa demos directly on Wayland (ie, EGL as oposed to GLUT+X11).

> And in general, many/most of the Mesa demos have some interactive aspect 
> to them (key presses or mouse input) that isn't available in waffle or 
> piglit (I'm not familiar with glfw).  And few of the Mesa demos do pixel 
> probing for correctness.
I believe glfw3 has similiar design to glut (ie not too hard to port), 
but supports Wayland, EGL, and input too.

But google around a bit more, it seems freeglut also supports wayland, 
so perhaps doesn't really matter.

Jose