Does this bug reproduce on master?  I recently fixed a nasty bug on master related to this.

Yes I confirmed the behavior exists on master.

You can repro the behavior with the LunarG cube demo:

1) In the driver's x11 swapchain, change the image tiling from X to Y. This is necessary because an aux surface is created only for Y tiled surfaces.

anv_wsi.c (anv_wsi_image_create):
  pass 0 as .isl_tiling_flags instead of ISL_TILING_X_BIT
  pass I915_TILING_Y to anv_gem_set_tiling instead of I915_TILING_X

2) Change the finalLayout in demo_prepare_render_pass

cube.c (demo_prepare_render_pass):
   change finalLayout to VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL instead of VK_IMAGE_LAYOUT_PRESENT_SRC_KHR

So 2) is technically invalid in this case because the image is being presented.

However in my application the image isn't being presented directly.  Instead, the buffer is being imported into another process which reads from the image as a texture.

Created attachment 135715 [details]
background color clear missing

Ok, in that case, I know exactly what bug you're hitting and I'm in the process of fixing it so we can enable modifiers for X11 and Wayland WSI. Expect to see a flood of patches on mesa-dev early next week.

Great.  Will the fixes be applied back to 17.2?

(In reply to Craig Stout from comment #5)
> Great.  Will the fixes be applied back to 17.2?

I was not planning to as the bug cannot be hit with the current upstream X11 and Wayland parts.  Can you hit this with upstream Android it do you need additional patches?

I don't know about Android; I don't typically try this.  How do you go about testing android typically?

For 17.2, this is my only problem.

(In reply to Craig Stout from comment #7)
> I don't know about Android; I don't typically try this.  How do you go about
> testing android typically?

I don't.  I just saw your email address and figured maybe you were going this in ARC.  The only way I can imagine hitting this is either on Android or with extra patches on top.

> For 17.2, this is my only problem.

I think it's reasonable to backport to 17.3 but since it doesn't fix a hittable bug without out-of-tree patches so far as I can tell, I don't think it will get backported to 17.2.  I plan to send the patches today.

I can hit the bug in 17.2 without modifications to mesa.  It's a somewhat complicated use-case: the color attachment that fails to be cleared is read by another process as a texture.

Jason fyi, just retested master and I'm still seeing the problem.

Are you using the hacky INTEL external extension?

No.  For the primary use case, we have a different "custom" (won't call it hacky haha) extension for importing/exporting buffers.

But for the purpose of evaluating latest master, I'm using the recipe described in Comment 2 since it seems to demonstrate the issue in a fairly isolated manner.

(In reply to Craig Stout from comment #12)
> No.  For the primary use case, we have a different "custom" (won't call it
> hacky haha) extension for importing/exporting buffers.
> 
> But for the purpose of evaluating latest master, I'm using the recipe
> described in Comment 2 since it seems to demonstrate the issue in a fairly
> isolated manner.

What image layout are you using when you transfer between processes?

When the image is generated the image layout in the producer's render pass is always VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.

I'm closing this as NOTABUG becuase it's not something that's possible to hit on upstream mesa without out-of-tree patches.  (Modifying WSI counts as out-of-tree patches).  I'll be sending you an e-mail so that we can continue this discussion and figure out how to solve your problem long-term.