Bug 92184

Summary: Many piglit assertion failures in radeon_unmap_renderbuffer
Product: Mesa Reporter: Ian Romanick <idr>
Component: Drivers/DRI/R100Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
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

    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]
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.