[Intel-gfx] Incorrect limitation?

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Galibert wrote:

> 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.

The issue with all of those formats is that the driver and core Mesa do
not support them.  The only additional formats that we could expose now
are the 32-bit + 16-bit modes.  For example, RGBA8888 with DEPTH16.  A
fair amount of work would need to be done in Mesa to support >8-bits per
color component.  FP32 depth would be less work, but I don't think
anyone is currently signed up to do it.

Patches welcome. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktwUDkACgkQX1gOwKyEAw9cVQCbBAPxX1MT+VgSHD3hR/hu/ykQ
+ksAn2yIixomqGY14+wBUKJ0Fa+Aj3Yx
=CUOh
-----END PGP SIGNATURE-----