Bug 110765 - ANV regression: Assertion `pass->attachment_count == framebuffer->attachment_count' failed
Summary: ANV regression: Assertion `pass->attachment_count == framebuffer->attachment_...
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Bas Nieuwenhuizen
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: mesa-19.2
  Show dependency treegraph
 
Reported: 2019-05-27 10:01 UTC by Eero Tamminen
Modified: 2019-09-09 10:36 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Eero Tamminen 2019-05-27 10:01:24 UTC
GfxBench v5.0 GOLD2 Vulkan AztecRuins started failing nearly week ago. 

Setup:
- Ubuntu 18.04
- Unity / compiz desktop
- Mesa from git
- X server and drm-tip kernel from git, with modifier support enabled
- FullHD monitor

Test-case:
- Vulkan AztecRuins:
  bin/testfw_app --gfx vulkan --gl_api vulkan --width 1920 --height 1080 --fullscreen 1 --test_id vulkan_5_normal

Expected result:
- Works like earlier

Actual result:
- After benchmark has compiled its shaders and starts running:
  src/intel/vulkan/genX_cmd_buffer.c:1191: gen9_cmd_buffer_setup_attachments: Assertion `pass->attachment_count == framebuffer->attachment_count' failed.

Regression happened between following commits:
- 2019-05-18 10:15:04 ccb8ea7acf: meson: expose glapi through osmesa
- 2019-05-19 00:38:03 4689e98fe8:vulkan/wsi: Set X11 minImageCount to 3

Few of the Sacha Willems' Vulkan demos that are also run, don't have the same problem.
Comment 1 Mark Janes 2019-05-28 20:20:41 UTC
Bas, this assertion hits due to your commit:

   4689e98fe8:vulkan/wsi: Set X11 minImageCount to 3
Comment 2 Bas Nieuwenhuizen 2019-05-28 23:40:26 UTC
If No Mans Sky is any indication, this is likely an issue where the app does not account for the increased number of images.

Sadly, I still have no access to Aztec Ruins, so really cannot debug this ...
Comment 3 Eero Tamminen 2019-05-29 07:59:47 UTC
(In reply to Bas Nieuwenhuizen from comment #2)
> If No Mans Sky is any indication, this is likely an issue where the app does
> not account for the increased number of images.

If there are two apps with this bug, there are likely to be more.

What would be best way to deal with this:
- drop minImageCount to 2 (is this something app request?)
- driconf variable for buggy apps
- something else
?


> Sadly, I still have no access to Aztec Ruins, so really cannot debug this ...

Mark, can you check that?

(Jason has looked more into AztecRuins and I think he has some contact at Kishonti to ask whether they will ever release a newer / fixed version.  If not, probably better to drop AztecRuins.)
Comment 4 Bas Nieuwenhuizen 2019-05-29 10:35:09 UTC
On Wed, May 29, 2019 at 9:59 AM <bugzilla-daemon@freedesktop.org> wrote:
>
> Comment # 3 on bug 110765 from Eero Tamminen
>
> (In reply to Bas Nieuwenhuizen from comment #2)
> > If No Mans Sky is any indication, this is likely an issue where the app does
> > not account for the increased number of images.
>
> If there are two apps with this bug, there are likely to be more.

Yeah .. It is clearly allowed by spec though and NMS had other issues
too (could not deal with maxImageCount = 0). NMS is actually fixed
these days and does not break anymore with high minImageCount.

>
> What would be best way to deal with this:
> - drop minImageCount to 2 (is this something app request?)

Thing is only having 2 images can really hurt performance in fullscreen.

> - driconf variable for buggy apps

That was what I was going for.

> - something else
> ?
>
>
> > Sadly, I still have no access to Aztec Ruins, so really cannot debug this ...
>
> Mark, can you check that?
>
> (Jason has looked more into AztecRuins and I think he has some contact at
> Kishonti to ask whether they will ever release a newer / fixed version.  If
> not, probably better to drop AztecRuins.)
>
> ________________________________
> You are receiving this mail because:
>
> You are the assignee for the bug.
Comment 5 Eero Tamminen 2019-05-31 09:35:07 UTC
(In reply to Bas Nieuwenhuizen from comment #4)
> > Comment # 3 on bug 110765 from Eero Tamminen
> > - driconf variable for buggy apps
> 
> That was what I was going for.

In AztecRuins case, there's a problem that GfxBench is a benchmark with multiple test-cases, and workaround is needed only for AztecRuins test (which is in the latest version the only test supporting Vulkan).

For the command line version of GfxBench, such option would need to match also command line options ("vulkan_5_*").
Comment 6 Jason Ekstrand 2019-08-10 13:05:28 UTC
Ping.  Do we have a driconf variable for this?  Does someone just need to wire up the driconf stuff in anv?
Comment 7 Eero Tamminen 2019-08-29 07:40:02 UTC
(In reply to Eero Tamminen from comment #5)
> (In reply to Bas Nieuwenhuizen from comment #4)
> > > Comment # 3 on bug 110765 from Eero Tamminen
> > > - driconf variable for buggy apps
> > 
> > That was what I was going for.
> 
> In AztecRuins case, there's a problem that GfxBench is a benchmark with
> multiple test-cases, and workaround is needed only for AztecRuins test
> (which is in the latest version the only test supporting Vulkan).

Additionally, the names of the binaries for all GfxBench versions are the same, and there are two of those binaries, GUI and command line version.


> For the command line version of GfxBench, such option would need to match
> also command line options ("vulkan_5_*").

Or "vulkan_*", if this is a generic issue on GfxBench Vulkan backend.  Not sure what to do with the GUI version.
Comment 8 Eero Tamminen 2019-08-30 09:43:36 UTC
Verified that Eric's MR would fix this also for me:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1819
Comment 9 Eero Tamminen 2019-09-09 10:36:25 UTC
Eric merged his MR and onscreen Vulkan Aztec Ruins test works again.


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.