vkCmdBlitImage w/ alpha

Is there a way to use vkCmdBlitImage, or a similar function, while taking into account the image’s alpha channel?

Back in the day, hardware used to have blit operations that cared about “transparent pixels”. But that day was a long time ago. And even then, “transparent pixels” were almost never alpha channels; they were a color key, a specific color designated to mean “transparent”.

When you want to do the kind of thing you’re wanting to do nowadays, we call that “rendering”. You just render a quad of the appropriate size in the appropriate location, using a shader that accesses the appropriate texture, with an appropriate blending mode.

I see. So it’s impossible to draw a texture directly to screen while taking into account the alpha channel. Is it possible to do so without a vertex shader though?
I new to both Vulkan and OpenGL so I apologize if any of these questions are stupid; I’m pretty sure they are :stuck_out_tongue:

Is it possible to do so without a vertex shader though?

No. You need to use a rendering operation, and all rendering operations require a vertex shader. I don’t know why that’s such an onerous burden, since you also need to set up the rest of the rendering pipeline, as well as vertex buffers and the like.

It really isn’t actually. Thank you :slight_smile:

Really? Vulkan makes me go to great lengths to specify the color format of images and then completely ignore it in some operations?

Of course I can render it, but if my image is already finished and I could copy/blite it directly to the framebuffer, no render operation can be that efficient.

I’m disappointed!

Specifying a color format is not a “great length”. Also, just because an image has an alpha component doesn’t mean that doing blending during a blit is desired.

Doesn’t that presume that the GPU has hardware that can do alpha blending while blitting?

> Specifying a color format is not a “great length”

Ok, not a great lenght. But choosing from over 190 color formats every time has some effort for me. In addition, I still have to test and remember which function evaluates which part of the color information, because the Reference Guide doesn’t tell you that. And know that I define the color format in the VkImageView, but then it is also considered in operations that only use a VkImage.

Doesn’t that presume that the GPU has hardware that can do alpha blending while blitting?

Not if my source image comes directly from my image editing software.

I don’t just want to complain, so my main point would be: It would be useful if this and a lot of other meta-information could be looked up in the reference guide.
It would be even nicer if VkImageBlit got an entry alphaBlendingMode with 0 as the default value for the current behavior. In line with the Vulkan philosophy that the user has to specify exactly what he wants.

What exactly is the “this” you are referring to? That vkCmdBlitImage doesn’t do blending? The reference for that function doesn’t say that it does blending. What other things should it say that the function doesn’t do?

I think you misunderstood what I meant when I said “Doesn’t that presume that the GPU has hardware that can do alpha blending while blitting?”

In order for your hypothetical alphaBlendingMode to work, the hardware that actually performs a blit would have to be able to do blending. What if it can’t? What if most blitting hardware doesn’t?

It should also be noted that, while there are a fair number of extensions, none of them include blended blitting. So either hardware in general can’t do it, or nobody cares enough to expose the functionality.

1 Like

In short, just use a compute shader :slight_smile:

Nice you mentioned it. Please take a look into you own link, there is no notice about blending, only the phrase “potentially performing format conversion”. Your statement is right for vkCmdCopyImage, there is explicit stated that no blending is performed.

Ok, I understand Vulkan can’t support operations if the GPU doesn’t. I had mistakenly assumed that every GPU can do this, because fragmentation shaders always have an alpha channel.

Right… because it doesn’t do blending. If it did blending, it would say so. It’s unreasonable to expect documentation to list all of the things a function doesn’t do.

The documentation is very clear:

To copy regions of a source image into a destination image, potentially performing format conversion, arbitrary scaling, and filtering, call

Blending isn’t on that list.

And yes, I agree: it is really weird that vkCmdCopyImage tries to list a bunch of things it doesn’t do. But even that list is not comprehensive; yes, it mentions blending, but it doesn’t mention logical operations. That doesn’t mean it allows performing logical operations.

Fragments are the result of rasterization. Rasterization is the result of primitives. And primitives are the result of rendering operations. Which was what this entire thread was about avoiding.

So what fragment shaders do (or don’t do; FS’s do not do blending) is not relevant to what blitting does, since blitting is explicitly not a rendering operation.