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]
It appears that this happens whenever a software fallback occurs... and there are a lot of software fallbacks in the r100 drivers.
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?
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>
-- 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.
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.