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 <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
