[Intel-gfx] Incorrect limitation?
galibert at pobox.com
Tue Feb 9 09:06:53 CET 2010
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 :-)
More information about the Intel-gfx