https://bugs.freedesktop.org/show_bug.cgi?id=92184
Bug ID: 92184 Summary: Many piglit assertion failures in radeon_unmap_renderbuffer Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R100 Assignee: dri-devel@lists.freedesktop.org Reporter: idr@freedesktop.org QA Contact: dri-devel@lists.freedesktop.org
While doing other things, I noticed quite a few piglit tests crashing with
radeon_fbo.c:454: radeon_unmap_renderbuffer: Assertion `ok' failed.
This occurs when r100_blit fails. Just skimming the code, there are a LOT of reasons that r100_blit could return false, so it seems like there should be some fallback path. Some (perhaps all?) of the failures also log
WRITE DOMAIN RELOC FAILURE 0x1 6 4
Some tests that fail in this manner are:
bin/fbo-depthstencil copypixels default_fb -auto bin/stencil-drawpixels -auto bin/texsubimage -auto bin/tex3d-depth1 -auto -fbo
There are many others. On my last run there were 39 crashes (out of 1072 tests not skipped), and most of those seem to be this assertion.
If it matters, this was on:
Linux grundgetta.home 4.1.6-201.fc22.x86_64 #1 SMP Fri Sep 4 17:49:24 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
00:01.0 PCI bridge [0604]: Intel Corporation 82865G/PE/P AGP Bridge [8086:2571] (rev 02) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV200 [Radeon 7500/7500 LE] [1002:5157]
https://bugs.freedesktop.org/show_bug.cgi?id=92184
--- Comment #1 from Ian Romanick idr@freedesktop.org --- It appears that this happens whenever a software fallback occurs... and there are a lot of software fallbacks in the r100 drivers.
https://bugs.freedesktop.org/show_bug.cgi?id=92184
--- Comment #2 from Roland Scheidegger sroland@vmware.com --- Not sure, but I don't think there should be a fallback for the blit in this case. This is for map/unmap_renderbuffer after all, and if it asserts in unmap this means the blit from the rb to some temp buffer was succesful. I see no reason why it shouldn't be possible to blit it back - it was a rb after all, so should have all the required alignment, format etc. in the first place. Some of the examples you listed actually look like they should only really map/unmap zs buf not color, albeit the fallback might just map/unmap everything always (IIRC that was actually the case last I checked several years ago, and sometimes responsible for some huge slowdown compared to some old dri1 code - you draw a single point with some unsupported setup, and 99.999% of the time spent in the fallback was just for blitting everything to some buffer and back). Or could there be a problem if there's not actually a color rb and it tries to blit that?
https://bugs.freedesktop.org/show_bug.cgi?id=92184
--- Comment #3 from Timothy Arceri t_arceri@yahoo.com.au --- The problem starts happening with this commit:
commit 085a86154553d86f8e4296b4c732901f781bdfd8 Author: Marek Olšák marek.olsak@amd.com Date: Fri Aug 1 19:36:37 2014 +0200
radeon,r200: fix buffer validation after CS flush
This validates all bound buffers (CB, ZB, textures, DMA) at the beginning of CS. This fixes "bo->space_accouned" assertion failures.
Tested by: Jochen Rollwagen joro-2013@t-online.de Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Alex Deucher alexander.deucher@amd.com
https://bugs.freedesktop.org/show_bug.cgi?id=92184
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #4 from GitLab Migration User gitlab-migration@fdo.invalid --- -- 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/288.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org