dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 108824] Invalid handling when GL buffer is bound on one context and invalidated on another
Date: Wed, 21 Nov 2018 20:35:15 +0000	[thread overview]
Message-ID: <bug-108824-502@http.bugs.freedesktop.org/> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2707 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=108824

            Bug ID: 108824
           Summary: Invalid handling when GL buffer is bound on one
                    context and invalidated on another
           Product: Mesa
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: baldurk@baldurk.org
        QA Contact: dri-devel@lists.freedesktop.org

Created attachment 142556
  --> https://bugs.freedesktop.org/attachment.cgi?id=142556&action=edit
piglit test showing broken behaviour

I found some odd behaviour that I think I've tracked down to some incorrect
handling of buffer invalidation in radeonsi.

The rough order of events is:

1. Create a buffer that's shared between two contexts. Ensure it's bound as a
UBO on both.
2. Invalidate the buffer with e.g.
glMapBufferRange(GL_MAP_INVALIDATE_BUFFER_BIT) on context A.
3. Context B's buffer bind is now in a bad state. Rendering will have
unpredictable results, and invalidating the buffer again on context B may fail.

That's a bit vague but that's the general repro that I know for sure. This will
then result in unpredictable reads/garbage data, and quite likely you'll
eventually hit the assert on src/gallium/drivers/radeonsi/si_descriptors.c:1489
- assert(old_buf_va <= old_desc_va);

My understanding is that the radeonsi code will look through all bound buffers
whenever an invalidate happens, fixup the descriptors by subtracting the
descriptor's VA from the outgoing VA for the old buffer to get the offset, then
add it onto the incoming VA and update the descriptor.

The problem seems to be that when this happens for a buffer invalidate it only
checks the current context's bound buffers - so other contexts don't have their
descriptors updated. That means the old VA is still being pointed at, and if an
invalidate happens again on the second thread the descriptor is referring to an
even older VA than the outgoing VA so there's no longer any sense in the
subtract call.

I've attached a piglit test which hopefully should drop right in, it runs
through the steps above and does a pixel readback to ensure the rendering went
correctly. If you remove the readback you can see flickering output. It runs
fine with both the readback and the rendering if I switch to swrast.

I'm on an RX 480 and tested the bug with both git-61b535437e and 18.2.4 from
padoka's PPA.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2018-11-21 20:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21 20:35 bugzilla-daemon [this message]
2019-02-01 15:26 ` [Bug 108824] Invalid handling when GL buffer is bound on one context and invalidated on another bugzilla-daemon
2019-02-01 15:27 ` bugzilla-daemon
2019-03-22 16:56 ` bugzilla-daemon
2019-05-10  5:22 ` bugzilla-daemon
2019-05-13 21:47 ` bugzilla-daemon
2019-05-13 21:53 ` bugzilla-daemon
2019-05-16 16:34 ` bugzilla-daemon
2019-05-19 23:29 ` bugzilla-daemon
2019-05-20 13:47 ` bugzilla-daemon
2019-05-20 13:48 ` bugzilla-daemon
2019-05-21  8:40 ` bugzilla-daemon
2019-05-21 16:28 ` bugzilla-daemon
2019-05-21 18:35 ` bugzilla-daemon
2019-05-21 20:53 ` bugzilla-daemon
2019-05-22 21:59 ` bugzilla-daemon
2019-09-25 18:29 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-108824-502@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).