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/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 : Intel Corporation 82865G/PE/P AGP Bridge [8086:2571] (rev 02)
01:00.0 VGA compatible controller : 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:
Author: Marek Olšák <firstname.lastname@example.org>
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 <email@example.com>
Reviewed-by: Alex Deucher <firstname.lastname@example.org>
-- 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.