Bug 102123 - [llvmpipe] piglit gl-3.2-layered-rendering-framebuffertexture regression
Summary: [llvmpipe] piglit gl-3.2-layered-rendering-framebuffertexture regression
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
Keywords: bisected, regression
Depends on:
Reported: 2017-08-09 00:24 UTC by Vinson Lee
Modified: 2017-08-17 00:27 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Description Vinson Lee 2017-08-09 00:24:27 UTC
mesa: c12c2e40a36f707f733c0d6ad90160472b7a3cf6 (master 17.3.0-devel)

$ ./bin/gl-3.2-layered-rendering-framebuffertexture -auto
Unexpected framebuffer status!
Texture Type: GL_TEXTURE_2D_MULTISAMPLE. Error during setup.
Texture Type: GL_TEXTURE_2D_MULTISAMPLE. FramebufferTexture() Test Failed.
Unexpected framebuffer status!
Texture Type: GL_TEXTURE_2D_MULTISAMPLE_ARRAY. Error during setup.
Texture Type: GL_TEXTURE_2D_MULTISAMPLE_ARRAY. FramebufferTexture() Test Failed.
PIGLIT: {"result": "fail" }

6839d3369905eb02151334ea7b4cd39ddcfa6770 is the first bad commit
commit 6839d3369905eb02151334ea7b4cd39ddcfa6770
Author: Brian Paul <brianp@vmware.com>
Date:   Tue Aug 1 21:28:25 2017 -0600

    st/mesa: fix handling of NumSamples=1 (v2)
    In Mesa we use the convention that if gl_renderbuffer::NumSamples
    or gl_texture_image::NumSamples is zero, it's a non-MSAA surface.
    Otherwise, it's an MSAA surface.  But in gallium nr_samples=1 is a
    non-MSAA surface.
    Before, if the user called glRenderbufferStorageMultisample() or
    glTexImage2DMultisample() with samples=1 we skipped the search for the
    next higher number of supported samples and asked the gallium driver to
    create a surface with nr_samples=1.  So we got a non-MSAA surface.
    This failed to meet the expection of the user making those calls.
    This patch changes the sample count checks in st_AllocTextureStorage()
    and st_renderbuffer_alloc_storage() to test for samples > 0 instead of > 1.
    And we now start querying for MSAA support at samples=2 since gallium has
    no concept of a 1x MSAA surface.
    A specific example of this problem is the Piglit arb_framebuffer_srgb-blit
    test.  It calls glRenderbufferStorageMultisample() with samples=1 to
    request an MSAA renderbuffer with the minimum supported number of MSAA
    samples.  Instead of creating a 4x or 8x, etc. MSAA surface, we wound up
    creating a non-MSAA surface.
    Finally, add a comment on the gl_renderbuffer::NumSamples field.
    There is one piglit regression with the VMware driver:
    ext_framebuffer_multisample-blit-mismatched-formats fails because
    now we're actually creating 4x MSAA surfaces (the requested sample
    count is 1) and we're hitting some sort of bug in the blitter code.  That
    will have to be fixed separately.  Other drivers may find regressions
    too now that MSAA surfaces are really being created.
    v2: start quering for MSAA support with samples=2 instead of 1.
    Reviewed-by: Roland Scheidegger <sroland@vmware.com>
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>

:040000 040000 ce8996d82890c153e42edd49df6c4d4a09a10241 2986ed81a0e5f36dfe70d4a3438613251583f4ce M	src
bisect run success
Comment 1 Roland Scheidegger 2017-08-09 16:25:06 UTC
If that's only softpipe/llvmpipe regressing, it is most likely due to only having fake msaa support.
I'm a bit surprised the test result changed, but I suppose the test previously actually used a msaa texture with just 1 sample, which now gets upgraded automatically to 2 samples. Albeit I can't quite tell why this particular result changed, since mostly the nr_samples in the resource should be ignored. In any case, we don't handle msaa correctly, so one or two more tests failing in that area (bug 102125 is really more of the same) isn't much of an issue (albeit it's too bad we can't stop (most of) the tests trying even though we report a maximum number of 0 samples).
If hw drivers fail too that would be definitely worrying.
Comment 2 Brian Paul 2017-08-17 00:27:08 UTC
Commit 9fbb0bf7e60a36113d96ac8a9622ba348def535e checks if MSAA is really supported before testing the multisample texture targets.

Closing this bug.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.