-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/15/2012 11:12 AM, Paul Berry wrote:
> Due to hardware limitations, MSAA is unsupported on Gen6 for formats
> containing >64 bits of data per pixel. From the Sandy Bridge PRM,
> vol4 part1, p72 ("Surface Format"):
>
> If Number of Multisamples is set to a value other than
> MULTISAMPLECOUNT_1, this field cannot be set to the following
> formats:
> - any format with greater than 64 bits per element
> - any compressed texture format (BC*)
> - any YCRCB* format
>
> Gen7 has a similar, but less stringent limitation: formats with >64
> bits of data per pixel only support 4x MSAA.
>
> This patch causes the unsupported formats to report
> GL_FRAMEBUFFER_UNSUPPORTED.
>
> Fixes piglit "multisample-formats" tests on Gen6.
> ---
>
> It is not 100% clear to me whether this approach is compliant with the
> spec. On the one hand, the spec requires formats RGBA32F, RGBA32I,
> and RGBA32UI to be color-renderable. On the other hand, the spec
> allows for the implementation to report GL_FRAMEBUFFER_UNSUPPORTED if
> the set of attached images violates "an implementation-dependent set
> of restrictions", which seems to leave a lot of leeway.
>
> If we decide that it's not ok to report GL_FRAMEBUFFER_UNSUPPORTED for
> MSAA buffers using these formats, then we'll have to figure out some
> other way to work around the hardware's lack of support for MSAA on
> these formats, and I haven't thought of a good way to do that. The
> alternatives I've considered (substitute another buffer format, or
> substitute a non-multisampled renderbuffer) are definitely
> non-spec-compliant, and also fraught with implementation difficulties.
>
> So for the moment my inclination is to go through with this patch as
> is, and if we later discover that it causes trouble for a client
> application, we can consider other options. I'm curious to hear what
> others think.
After releasing GL3.0, but before implementing real MSAA, we lied to the app.
If the app requested an MSAA buffer, we said "ok" and just created a
single-sample
buffer.
Can we do that for these formats? It may be better to do that than report
GL_FRAMEBUFFER_UNSUPPORTED. I'm unsure what's best, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP26yvAAoJEAIvNt057x8iJjAP/RSt81atGhBXTqBgBjmTwDrc
Y96MJxenirLr2MM8XzYUtYP+iOLvcYpYqJSpYpt6m7RCmLapnQTsYflh+QDD83Ba
ZJIxuBEM3ILflPNVp2YY+dBkVlq4TNMSONsOeOR1P/ro6EyBrnHhsKz3dODlzfZ5
vSSli6xS/blTiKFODQck5lhJi5FSwHxEfF/IbZKWkxULzFTrOOIHg7dns8YYtmI/
CeG1XdNuwc7tes9hh81uRNNR0kXXDv+0ph79w7JbQVbNdGSQYw037w+TVG7QJNMk
8ZPDqGyl7U+6jx8TyWtrZG+BMlIC13vSfSkPWmVpaGKXp/BfMwkXfuCcry4BeQfz
r1zFRSTvaZG3xQNOD8n5YKaZBOdI4AmRdJlRX8OQbpZpI+V6fZaG6qkxliTpF6yu
qc81yL96UMQoqNCkSCH4bp5r95QvxlxXv3xKrup0ORnw+ExzRd+Iq7B9sQbga1nw
tjoRdLPReWI++eWKFfsP1ew8+dMdQP+ENZkBdi/WDjnuXQFSqvqmUp1VWifVLXCv
mHXlGd62Vo9Urb6qDmKbUgbYyewaAtAV756L0ytvlv8+zdf7a4wtePsbJW4+cN0G
nzsHVryS6maT8nLizCIlkXT+y6NSzV2+Lt5Yq9pU76NCfsEpqbI+OxbMvLbPa81/
1yo9AjVqJ1SyuX+fXMyp
=/emk
-----END PGP SIGNATURE-----
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
