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
next 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).