[Mesa-dev] sRGB in gallium (was: allow rendering to sRGB textures if EXT_fb_srgb is unsupported)

[Dave Airlie]

On Thu, Feb 10, 2011 at 6:47 PM, José Fonseca <jfonseca at vmware.com> wrote:
> On Wed, 2011-02-09 at 17:55 -0800, Dave Airlie wrote:
>> On Thu, Feb 10, 2011 at 11:27 AM, Marek Olšák <maraeo at gmail.com> wrote:
>> > In this case, we always use the corresponding linear format in create_surface,
>> > therefore we should check for linear format support as well.
>>
>> Seems sane to me.
>>
>> Dave.
>
>
> The patch looks good to me.
>
> But it reminds me of something I've been planning to ask here for some
> time now:
>
> Wouldn't it be easier/cleaner if sRGB sampling/rendering support was not
> done through formats, but through enable/disable bits in
> pipe_sampler_view/pipe_rt_blend_state?

I considered this, but I thought it was possibly a GL only thing and
as such deserved to just hide
behind sampler views and surfaces, and I'm not sure its ended up that
ugly doing it like this.

The hardware at least on r600 has an sRGB bit in the surface state, so
it would end up as one
of those cross-state fiddling things. The sampler also has a bit you
set in the format registers.

> I know that DX9 has it as a state, DX10 doesn't even have SRGB anywher
> -- I suppose it has to handed in the shaders.
>
> How does the recent hardware cope with this? different RGB/sRGB formats,
> sampling/rendertarget state, or shader instruction?

sampling/rendertarget state for r600 at least, intel seems to use a
different surface format.

Dave.