Bug 92184 - Many piglit assertion failures in radeon_unmap_renderbuffer
Summary: Many piglit assertion failures in radeon_unmap_renderbuffer
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
Depends on:
Reported: 2015-09-29 21:24 UTC by Ian Romanick
Modified: 2019-09-18 18:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Ian Romanick 2015-09-29 21:24:16 UTC
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


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]
Comment 1 Ian Romanick 2015-11-30 23:27:27 UTC
It appears that this happens whenever a software fallback occurs... and there are a lot of software fallbacks in the r100 drivers.
Comment 2 Roland Scheidegger 2015-12-01 00:26:42 UTC
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?
Comment 3 Timothy Arceri 2016-02-05 05:39:56 UTC
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>
Comment 4 GitLab Migration User 2019-09-18 18:40:51 UTC
-- 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.