OpenHarmony/third_party_mesa3d
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

mesa/main: account for RTT samples when updating framebuffer

Browse Source 
For EXT_multisampled_render_to_texture, we store the number of samples
in Attachment->NumSamples instead of Renderbuffer->NumSamples. This
meant that the previous code ignored that the framebuffer was
multisampled. Because of this, pipe_rasterizer_state::multisample is set
incorrectly, leading to visual artifacts on drivers that support MS-RTT
extension, such as panfrost.

Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10747>
This commit is contained in:
Italo Nicola
2021-05-14 11:25:42 +00:00
committed by Marge Bot
parent ba72946fa3
commit 4d1a07c1a0
1 changed files with 24 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
src/mesa/main/framebuffer.c
View File

@@ -423,15 +423,36 @@ _mesa_update_framebuffer_visual(struct gl_context *ctx,
/* find first RGB renderbuffer */ /* find first RGB renderbuffer */
for (unsigned i = 0; i < BUFFER_COUNT; i++) { for (unsigned i = 0; i < BUFFER_COUNT; i++) {
if (fb->Attachment[i].Renderbuffer) { if (fb->Attachment[i].Renderbuffer) {
const struct gl_renderbuffer *rb = fb->Attachment[i].Renderbuffer; const struct gl_renderbuffer_attachment *att = &fb->Attachment[i];
const struct gl_renderbuffer *rb = att->Renderbuffer;
const GLenum baseFormat = _mesa_get_format_base_format(rb->Format); const GLenum baseFormat = _mesa_get_format_base_format(rb->Format);
const mesa_format fmt = rb->Format; const mesa_format fmt = rb->Format;
/* Grab samples and sampleBuffers from any attachment point (assuming /* Grab samples and sampleBuffers from any attachment point (assuming
* the framebuffer is complete, we'll get the same answer from all * the framebuffer is complete, we'll get the same answer from all
* attachments). * attachments). If using EXT_multisampled_render_to_texture, the
* number of samples will be on fb->Attachment[i].NumSamples instead
* of the usual rb->NumSamples, but it's still guarantted to be the
* same for every attachment.
*
* From EXT_multisampled_render_to_texture:
*
* Also, FBOs cannot combine attachments that have associated
* multisample data specified by the mechanisms described in this
* extension with attachments allocated using the core OpenGL ES
* 3.1 mechanisms, such as TexStorage2DMultisample. Add to section
* 9.4.2 "Whole Framebuffer Completeness":
*
* "* If the value of RENDERBUFFER_SAMPLES is non-zero, all or
* none of the attached renderbuffers have been allocated
* using RenderbufferStorage- MultisampleEXT; if the value of
* TEXTURES_SAMPLES is non-zero, all or none of the attached
* textures have been attached using Framebuffer-
* Texture2DMultisampleEXT.
* { GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT }"
*/ */
fb->Visual.samples = rb->NumSamples; fb->Visual.samples =
att->NumSamples ? att->NumSamples : rb->NumSamples;
if (_mesa_is_legal_color_format(ctx, baseFormat)) { if (_mesa_is_legal_color_format(ctx, baseFormat)) {
fb->Visual.redBits = _mesa_get_format_bits(fmt, GL_RED_BITS); fb->Visual.redBits = _mesa_get_format_bits(fmt, GL_RED_BITS);