Bug 92954 - [softpipe] piglit drawbuffer-modes regression
Summary: [softpipe] piglit drawbuffer-modes regression
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/softpipe (show other bugs)
Version: 11.1
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2015-11-14 22:40 UTC by Vinson Lee
Modified: 2019-09-18 18:27 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vinson Lee 2015-11-14 22:40:16 UTC
mesa: 3694d58e6c4a39bd84e8aef0d8e67c3ae9447f33 (master 11.1.0-devel)

$ ./bin/drawbuffer-modes -auto
Probe color at (20,20)
  Expected: 0.100000 0.200000 0.300000 1.000000
  Observed: 1.000000 1.000000 1.000000 1.000000
Probe color at (20,20)
  Expected: 0.300000 0.400000 0.500000 1.000000
  Observed: 1.000000 1.000000 1.000000 1.000000
Probe color at (20,20)
  Expected: 0.400000 0.500000 0.600000 1.000000
  Observed: 1.000000 1.000000 1.000000 1.000000
Probe color at (20,20)
  Expected: 0.600000 0.700000 0.800000 1.000000
  Observed: 1.000000 1.000000 1.000000 1.000000
glDrawBuffer(GL_NONE) modifies GL_FRONT_LEFT buffer
PIGLIT: {"result": "fail" }


2b676570960277d47477822ffeccc672613f9142 is the first bad commit
commit 2b676570960277d47477822ffeccc672613f9142
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Oct 9 01:38:08 2015 +0100

    gallium/swrast: fix front buffer blitting. (v2)
    
    So I've known this was broken before, cogl has a workaround
    for it from what I know, but with the gallium based swrast
    drivers BlitFramebuffer from back to front or vice-versa
    was pretty broken.
    
    The legacy swrast driver tracks when a front buffer is used
    and does the get/put images when it is mapped/unmapped,
    so this patch attempts to add the same functionality to the
    gallium drivers.
    
    It creates a new context interface to denote when a front
    buffer is being created, and passes a private pointer to it,
    this pointer is then used to decide on map/unmap if the
    contents should be updated from the real frontbuffer using
    get/put image.
    
    This is primarily to make gtk's gl code work, the only
    thing I've tested so far is the glarea test from
    https://github.com/ebassi/glarea-example.git
    
    v2: bump extension version,
    check extension version before calling get image. (Ian)
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91930
    
    Cc: <mesa-stable@lists.freedesktop.org>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 1726a5f7f01d9ae1fc76de431bb24cce16cf69ee 75f18ded95766bac58d0c37c96ffa071a4a32071 M	include
:040000 040000 ee333146b90c837460ceab252445e3b38fc528d5 dc0656326c3fb9750fda1f6d3e75aeed99003bc6 M	src
bisect run success
Comment 1 Vinson Lee 2016-03-22 02:19:03 UTC
mesa: 1e8435ce0cce671024ebf9c5465ea8bdcb563b69 (master 11.3.0-devel)

This regression is still present.
Comment 2 Karl Lessard 2017-01-08 20:55:20 UTC
The reason this has stopped working is because the drawable is not refreshed with the data written to the front buffer before reading its pixels.

Since https://cgit.freedesktop.org/mesa/mesa/commit/?id=2b676570960277d47477822ffeccc672613f9142, the drawable act as the source for reading the front buffer data. Since this test writes directly to the front buffer, all operations have to be flushed and reflected by the drawable before attempting to read it.

On a explicit flush, the state tracker take care of refreshing the drawable with the front buffer data after flushing (see st_glFlush). But in the drawbuffer-modes test, the flush is done implicitly by calling glReadPixels and is handled by the soft/llvm pipes themselves (see *pipe_transfer_map). The drawable does not get refreshed in this case, therefore when the test reads the front buffer data, it reads garbage.

It is tricky to refresh the drawable after flushing from the pipes because at that level, we don't know the nature of the resource being mapped for reading (front buffer, back buffer...). Unless I miss something?
Comment 3 GitLab Migration User 2019-09-18 18:27:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/215.


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.