[Intel-gfx] Incorrect limitation?

[Olivier Galibert]

On Mon, Feb 08, 2010 at 07:04:40PM +0100, Eric Anholt wrote:
> On Mon, 8 Feb 2010 11:04:13 +0100, Olivier Galibert <galibert at pobox.com> wrote:
> >   Hi all,
> > 
> > intel_screen.c says:
> >       /* With DRI2 right now, GetBuffers always returns a depth/stencil buffer
> >        * with the same cpp as the drawable.  So we can't support depth cpp !=
> >        * color cpp currently.
> >        */
> > 
> > and then proceeds to drop the depth bits to 16 and remove stencil for
> > 565 drawables.  But wandering around in intel_context.c I see that
> > GetBufferWithFormats looks correctly used when available.  So is that
> > an artefact from when before GBWF was available?
> > 
> > I don't really care about 565, but otoh fp32 depth, 4*s16 accumulation
> > buffers or u16/fp16/fp32 color channels are interesting and give bpp
> > mismatches between buffers.
> 
> Floating-point targets aren't supported due to patent issues,

Using floating point instead of fixed point is patented if you happen
to talk about colors?  Wow, I see the xor tradition is unrelenting.

> and if
> they were supported you'd get at them using FBOs instead of X visuals.

Yeah, the nvidia blob has them as GLXFBConfigs.


> If you're looking for 16 bits per channel color FBOs, you might start
> looking at extending mesa to do it and then enable it in the 965
> driver -- the AL16 code that exists should give you hints as to where to
> look to add support and what will be necessary.  If you're interested in
> accumulation buffers, you'd probably implement them using the existing
> FBO and shaders support.

I'm interested by accelerating accumulation buffers because I think
it's a good way to familiarize myself with the code.  Low, localized
impact.  What I'm really interested with (OpenGL 3.2) is not something
you _start_ with :-)

  OG.