[Mesa-dev] sRGB in gallium

[José Fonseca]

On Thu, 2011-02-10 at 02:06 -0800, Christoph Bumiller wrote:
> On 10.02.2011 09:47, José Fonseca 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 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?
> >
> nv50,nvc0 have both - SRGB framebuffer formats (but only for the
> A8B8G8R8/A8R8G8B8 formats) and an SRGB switch that can be made part of a
> cso.
> 
> But, I'm not sure if there is a difference between using an SRGB
> RT_FORMAT and using a non-SRGB format but setting the FRAMEBUFFER_SRGB bit.
> 
> Also, the sampler *views* have an orthogonal SRGB bit.

Everybody, 

Thanks for your replies. I get the impression that it looks doable and
net result looks positive but not really something we need to go out of
our way now to implement. 

> It's definitely not to be done in a shader though, blending wouldn't
> work properly that way I think.

Good point. D3D9 is a bit lenient about this, but I just checked that
EXT_framebuffer_sRGB.txt is not.

Jose