[Mesa-dev] [PATCH 3/4] llvmpipe: Only advertise unswizzled formats.

[Jose Fonseca]

----- Original Message -----
> On Thu, Nov 29, 2012 at 6:57 AM,  <jfonseca at vmware.com> wrote:
> > From: José Fonseca <jfonseca at vmware.com>
> >
> > Update llvmpipe_is_format_supported and
> > llvmpipe_is_format_unswizzled
> > so that only the formats that we can render without swizzling are
> > advertised.
> >
> > We can still render all D3D10 required formats except
> > PIPE_FORMAT_R11G11B10_FLOAT, which needs to be implemented in a
> > future
> > opportunity.
> 
> Does this affect GL? just wondering if we could have a bit more
> background on why this change is good etc..
> 
> I find it hard to review abstract changes with little reasoning in
> the
> commit msg, and I still have a passing interest in llvmpipe.

Sorry. This is something I announced I wanted to before - http://lists.freedesktop.org/archives/mesa-dev/2010-September/002664.html - but indeed it was a long time ago it wouldn't hurt adding a bit more context here.

Short story is, before llvmpipe was only able to render into swizzled tiles of 64x64 pixels in RGBA8 8bit unorm format. Pixels of all formats are converted into this, loosing precision in the process. So, even though llvmpipe advertised floating point render support, it was totally busted.

These patch series do two things: 
- eliminate the swizzled tiles (swizzling added so much complexity, and often had worse results that rendering straight to the render target)
- add support to render/blend straight to formats other than 8bi

So the result is that llvmpipe now renders preserving the whole dynamic range and accuracy, e.g., of floating point formats.

The only exception is PIPE_FORMAT_R11G11B10_FLOAT, an oddity, because it is not an array or an integer bitmask, so it will need special code to render it.

But this is just temporary (I plan to support it eventually), and furthermore llvmpipe can still sample from PIPE_FORMAT_R11G11B10_FLOAT just fine, falling back to u_format code.

I confess I assumed R11G11B10_FLOAT was not important for GL without checking. Looking at the code it seem EXT_packed_float will no longer be supported. Will this cause problems?

Jose