On Mon, Jun 12, 2017 at 10:43 PM, Jose Fonseca <jfons...@vmware.com> wrote: > 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.
Yeah the funny part and the reason is that we have a microbenchmark in piglit (drawoverhead) changing this state between draw calls. :) Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
