[Intel-gfx] Incorrect limitation?

Eric Anholt eric at anholt.net
Tue Feb 9 12:01:15 CET 2010


On Tue, 9 Feb 2010 09:06:53 +0100, Olivier Galibert <galibert at pobox.com> wrote:
> 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 :-)

Sounds like a fun project.  There's code doing similar stuff for
implementing glBitmap, glDrawPixels, and others in
src/mesa/drivers/common/meta.c, and I think you could build glAccum()
support using that style.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100209/86e080ab/attachment.sig>


More information about the Intel-gfx mailing list