AMD Driver 23.10.X and Newer Alpha mode not applied

[danielnehrig]

Description edited: For some reason on AMD cards with the latest drivers or recent drivers starting at driver 23.10 the alpha channel or composite alpha mode is not properly working anymore.

Repro steps have a amd gpu with latest drivers and try to set transparency via alpha channel

for alpha_mode

    // ... main
    simple_logger::init_with_level(log::Level::Debug).unwrap();
    let window = WindowHandling::create(); // how ever you wanna create your window winit or windows crate

    let target = SurfaceTarget::Window(Box::new(window)); // raw handle for surface target

    // setup wgpu
    let instance_desc = wgpu::InstanceDescriptor {
        flags: wgpu::InstanceFlags::empty(),
        backends: wgpu::Backends::VULKAN, // DX12, GL or VULKAN does not matter nothing works
        ..Default::default()
    };
    let wgpu_instance = wgpu::Instance::new(instance_desc);

    let surface = wgpu_instance.create_surface(target).unwrap();

    let adapter = wgpu_instance
        .request_adapter(&wgpu::RequestAdapterOptions {
            power_preference: wgpu::PowerPreference::default(),
            compatible_surface: Some(&surface),
            ..Default::default()
        })
        .await
        .expect("failed to create adapter");

    let surface_capabilities = surface.get_capabilities(&adapter);
    error!("{:?}", surface_capabilities.alpha_modes);
    let size = window.size();
        surface.configure(
        &device,
        &wgpu::SurfaceConfiguration {
            usage: wgpu::TextureUsages::RENDER_ATTACHMENT,
            format,
            width: size.0,
            height: size.1,
            present_mode: surface_capabilities.present_modes[0],
            alpha_mode: surface_capabilities.alpha_modes[0],
            desired_maximum_frame_latency: 2,
            view_formats: vec![],
        },
    );
    // end main

begin_render_pass

 // render pass
ops: wgpu::Operations {
    load: wgpu::LoadOp::Clear(wgpu::Color::TRANSPARENT),
    store: wgpu::StoreOp::Store,
},

Expected vs observed behavior Expected A texture / pixel alpha mode is respected on AMD. Background color transparency works on AMD.

Observed A texture / pixel alpha mode not respected on AMD. Background color is black on AMD

Extra related/similar issues #687

5150

Platform windows 11 wgpu = { version = "0.19" } AMD 7900 XTX on the 24.x driver (been thinking it might be Vulkan Driver issue)

[danielnehrig]

i've tested all drivers from https://www.amd.com/en/support/previous-drivers/graphics/amd-radeon-rx-7000-series/amd-radeon-rx-7900-series/amd-radeon-rx-7900xtx

last working driver is:

2024-03-11T00:34:49.140Z INFO  [wgpu_core::instance] Adapter Vulkan AdapterInfo { name: "AMD Radeon RX 7900 XTX", vendor: 4098, device: 29772, device_type: DiscreteGpu, driver: "AMD proprietary driver", driver_info: "23.8.2 (LLPC)", backend: Vulkan }

everything above in terms of version did not work for me

also https://www.amd.com/en/support/kb/release-notes/rn-rad-win-vulkan does not give much info what changed between the versions 23.8.2 (Works) and 23.10.2(not working)

this concludes my path down this stupid rabbit hole i hope it helps someone ...

[danielnehrig]

showcase for 23.12.1 driver showcase for 23.8.2 driver

[danielnehrig]

Newest 24.x drivers also not working

[lgrammer]

Just to confirm had this issue as well on 24.x drivers but only with Vulkan and DX12 backends. GL does actually work for me... but with a strange side effect (or two). This was with an older crate for both winit & wgpu(0.28/0.18).

I was getting an increased alpha value after a short delay using GL, and I can only run wgpu::CompositeAlphaMode in Opaque mode..? Updating my crates and code now to compare results and double-check things. Guessing the latter issue is from the older api but the issue with Vulkan/DX12 not working at all is from AMD (since past drivers were cited to work).

Sent a bug report to them and linked this issue just in case it is driver related.

[lgrammer]

edit: Posted too soon. Forgot to add with_transparent(true).. turns out GL still works for me just like before. So just Vulkan and DX12 still fully bugged out.

Trying to change wgpu::CompositeAlphaMode::Opaque to anything else provided in the crates docs still gets:

Caused by:
    Requested alpha mode Inherit is not in the list of supported alpha modes: [Opaque]

I'll post more specific information if it can help solve the bug per request. Just let me know. For now I'll leave it at that as to not clutter the issue with potentially unneeded information.

[danielnehrig]

fyi funny enough regarding CompositeAlphaMode on the working driver the alpha channel is applied even though its Opaque i had that initially pointed out as an issue since the docs state that alpha should not be taken into account but only in PreMultiplied but i removed it because i thought i might not fully understand how it works

[danielnehrig]

Just to confirm had this issue as well on 24.x drivers but only with Vulkan and DX12 backends. GL does actually work for me... but with a strange side effect (or two). This was with an older crate for both winit & wgpu(0.28/0.18).

I was getting an increased alpha value after a short delay using GL, and I can only run wgpu::CompositeAlphaMode in Opaque mode..? Updating my crates and code now to compare results and double-check things. Guessing the latter issue is from the older api but the issue with Vulkan/DX12 not working at all is from AMD (since past drivers were cited to work).

Sent a bug report to them and linked this issue just in case it is driver related.

also to confirm what you say GL is actually working i was very certain i did already try it also here it says Opaque

[lgrammer]

fyi funny enough regarding CompositeAlphaMode on the working driver the alpha channel is applied even though its Opaque i had that initially pointed out as an issue since the docs state that alpha should not be taken into account but only in PreMultiplied but i removed it because i thought i might not fully understand how it works

No worries. I too doubted the meaning of opaque for a second haha.

I went through the wgpu code and even the ash bindings. I don't think this issue relates directly to wgpu, as everything is properly exposed from what I've seen. We can confirm this by testing ash directly and replicating the bug.

Ash seems to be updated with the Vulkan specs and nothing in Vulkan changed in regards to alpha composite in the updates you linked. I'll go through the headers and Vulkan stuff later but I doubt anything will come of it.

https://github.com/ash-rs/ash/blob/master/ash/src/vk/bitflags.rs#L576

https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkCompositeAlphaFlagBitsKHR.html

Our next step to resolve this would be hooking up a window with ash and confirming 100 percent it's not wgpu. Then we can escalate the issue to the ash repo for now and close this out. If you don't have the time for that I may be able to do it later this week.

All roads probably just lead to AMD on this one. It might be worth posting a bug report directly in AMD forums after confirming it happens directly using ash (or Vulkan even). I sent mine in using the AMD software. If we can rule them out and get some visibility on this with AMD - I'm sure we can get this patched up rather quickly.

[lgrammer]

went ahead and tested ash really quick

pre and post multiply were completely broken and you get this and a crash. Using opaque/inherit ran without errors, however I'm not familiar with ash/vulkan enough to modify and test the alpha just yet and get any sort of visual confirmation on either of them.

I'll test for these same crashes on the last working driver you stated in a bit. It was pretty easy to get this going if you wanna confirm it on your end before we move the issue up the ladder a bit. Just install lunarg/vulkan sdk as stated in the ash readme, clone the repo and run the example. The composite alpha code is here:

either way I suppose this is enough to say this isn't a wgpu issue. let me know what you think

[lgrammer]

Same issue with the older driver you listed even. Not even opaque was working when I tried messing with alpha values in the triangles shader. Which is kinda odd if it was working for you with wgpu... Multiplied and tried it all again. Changed blend factor and tried again. Both opaque and inherit... Nothing working unfortunately. Other two options still crash. Might go through the code later and look through what was provided in the errors, swapchain stuff etc.

[danielnehrig]

went ahead and tested ash really quick

pre and post multiply were completely broken and you get this and a crash. Using opaque/inherit ran without errors, however I'm not familiar with ash/vulkan enough to modify and test the alpha just yet and get any sort of visual confirmation on either of them.

I'll test for these same crashes on the last working driver you stated in a bit. It was pretty easy to get this going if you wanna confirm it on your end before we move the issue up the ladder a bit. Just install lunarg/vulkan sdk as stated in the ash readme, clone the repo and run the example. The composite alpha code is here:

either way I suppose this is enough to say this isn't a wgpu issue. let me know what you think

i'll do just that and report back thanks for looking into it

[danielnehrig]

i looked into it and i can confirm the above mentioned behavior with ash

[lgrammer]

Cool thanks. Lets wait on further input before opening up an issue in ash or vulkan. My guess is the swapchain creation is bugging out with the surface? At this point I'm honestly not sure if it's a winit issue (since DX12 wasn't working with this surface either), Vulkan, AMD driver - or some odd combination of them.

Let us know what you guys think and how you want us to proceed with this. @Wumpf @teoxoy

[danielnehrig]

i don't think its winit i tested it a lot also i do my own window creation with the windows crate and create a raw window handle which i pass to wgpu

[lgrammer]

i don't think its winit i tested it a lot also i do my own window creation with the windows crate and create a raw window handle which i pass to wgpu

Just to clarify when I said winit I was more or less just trying to abstract from saying something like "window creation using the win32 API". Since that's what it does under the hood anyways. I just generally meant a windows surface.

Winit should be using the same window creation API you are using for a custom implementation so we wouldn't see a difference there. Sorry about that - I was being a bit lazy.

Don't suppose you have a Linux distro on one of your AMD machines by chance?

Funny enough you should be able to use winit to test if you do, as it should be cross platform iirc.

[danielnehrig]

i have arch installed but i haven't used it for quite a while i might be able to spin it up at the weekend and report back if it works under wayland

[panekj]

Experiencing same issue when using Vulkan backend, with OpenGL it works fine. System specs: AMD RX590, Fedora Kinoite 40 Trying the triangle example from ash repo, it works fine (although with lots of log noise)

INFO:
GENERAL [Loader Message (0)] :        Using "AMD Radeon RX 590 Series (RADV POLARIS10)" with driver: "/usr/lib64/libvulkan_radeon.so"

INFO:
VALIDATION [WARNING-cache-file-error (-1202627309)] : Validation Information: [ WARNING-cache-file-error ] | MessageID = 0xb8515d13 | vkCreateDevice():  Cannot open shader validation cache at /home/pj/.cache/shader_validation_cache-1000.bin for reading (it may not exist yet)

ERROR:
VALIDATION [VUID-vkAcquireNextImageKHR-semaphore-01779 (1461184347)] : Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0x140000000014, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)

[lgrammer]

Experiencing same issue when using Vulkan backend, with OpenGL it works fine. System specs: AMD RX590, Fedora Kinoite 40 Trying the triangle example from ash repo, it works fine (although with lots of log noise)

INFO:
GENERAL [Loader Message (0)] :        Using "AMD Radeon RX 590 Series (RADV POLARIS10)" with driver: "/usr/lib64/libvulkan_radeon.so"

INFO:
VALIDATION [WARNING-cache-file-error (-1202627309)] : Validation Information: [ WARNING-cache-file-error ] | MessageID = 0xb8515d13 | vkCreateDevice():  Cannot open shader validation cache at /home/pj/.cache/shader_validation_cache-1000.bin for reading (it may not exist yet)

ERROR:
VALIDATION [VUID-vkAcquireNextImageKHR-semaphore-01779 (1461184347)] : Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0x140000000014, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)

I was getting that same log noise as well just running it in Win11. Can you confirm if changing composite mode to pre and post multiplied crashes out on Fedora too? That's what we are looking for

You should potentially get the same validation error we did if it's bugged on a Linux surface too.

[panekj]

Can you confirm if changing composite mode to pre and post multiplied crashes out on Fedora too? That's what we are looking for

Sorry, did not understand well the previous conversation so didn't know to change anything.

Using PRE_MULTIPLIED I get proper transparent window with visual artifacts

Details


Using POST_MULTIPLIED I get no transparency but it launches fine

Details


[panekj]

I don't get any validation error about compositeAlpha, it's pretty much only spam of semaphore operations.

Let me know if I can verify anything else for you. I can re-boot to Windows later to cross-check the issue on same hardware.

[lgrammer]

Awesome. Thanks for that @panekj . Looks more and more like this bug might have to do with the Windows api not correctly passing surface capability during swapchain creation. At least that's my takeaway so far.

I'm not really sure how AMD drivers could impact the Win32 api in this regard. That's a bit outta scope for me. And so is testing the Win32 api directly.

I think it's safe to leave this be for a bit till wgpu contributors give their take on how they want to move the issue forward. Of course if you or anyone else wants to test stuff more, I'm sure it'll be of use to whoever this bug ultimately falls on to fix