From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7D8C63858411; Wed, 13 Oct 2021 16:36:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D8C63858411 From: "jon@solid-run.com" To: glibc-bugs@sourceware.org Subject: [Bug libc/28432] Aarch64 memcpy used on device-memory Date: Wed, 13 Oct 2021 16:36:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.32 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jon@solid-run.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 16:36:57 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28432 --- Comment #3 from Jon Nettleton --- (In reply to Wilco from comment #2) > (In reply to Jon Nettleton from comment #0) >=20 > > This does fix the issue I was trying to solve in both my specific test = case > > as well as a few real world rendering failures. Since we are only > > re-ordering stp's there should be no functional or performance regressi= ons, > > and all the glibc test's do pass. >=20 > It's not clear what the underlying issue is, but I don't believe reorderi= ng > stores would be sufficient - it might depend on alignment, state of the > writebuffer, cache miss/hit and many other factors that software can't > control. >=20 > So my first question is whether this works around the issue 100%, ie. for > all possible combinations of src and dst alignment, overlap (for memmove) > and sizes? This fixes a singular issue that we were seeing and was reproducible with t= his modified version of a previous test program that was done when the problem = was first detected on the Macchiatobin.=20 https://gist.github.com/jnettlet/80f8d09d01c0dc0ffc0122f36ed78de6 The issue addressed here is purely overlapping writes to device memory of s= izes 97-110 would have bytes starting or immediately after 64 bytes that would be either zero'd or unchanged. This behaviour could be successfully worked around by simple breaking up memcpy's of that size range into smaller copies.=20 https://gist.github.com/jnettlet/80f8d09d01c0dc0ffc0122f36ed78de6#file-fb_t= est-c-L98 This does not solve all GPU rendering issues, I have another patch for that= but this does resolve the issues in my test program, as well as rendering errors that were seen in glmark2 -b terrain as well as the game minetest that still existed with my mesa patch. Because these issues still existing with my patched mesa I believe this is a separate bug. This is another developer that reported the issues to me testing my glibc w= ith this patch included. https://twitter.com/sahajsarup/status/1445813643744985= 093 --=20 You are receiving this mail because: You are on the CC list for the bug.=