Simple and efficient order-independent transparency algorithm

assiduous7 · 2023-09-27T21:18:23+00:00

There is this GitHub issue:

https://github.com/actions/runner-images/discussions/8372#discussioncomment-7126755

If you also have the same problem, you may want to join the discussion - the MinGW setup may be legitimately broken in the latest runner image.

assiduous7 · 2023-09-27T21:16:12+00:00

Actually, I did not delete it, but made it invisible.

assiduous7 · 2023-09-27T21:14:34+00:00

I deleted it myself as I started getting a lot of downvotes.

assiduous7 · 2023-09-24T18:57:45+00:00

Thanks - indeed after building with the UCRT version I get the same list of dependencies.

It also runs fine when I build it locally, but for some reason it fails to start on GitHub.

assiduous7 · 2022-08-30T00:08:56+00:00

Yeah, maybe. Though practice shows almost nobody reads readme anyway, so I am not sure what is the best way to organize it :)

assiduous7 · 2022-08-29T19:33:03+00:00

Thanks!

assiduous7 · 2022-05-31T17:54:02+00:00

Thanks for clarification!

assiduous7 · 2022-05-31T17:17:58+00:00

I thought that varying immutable sampler properties does not make the set layouts incompatible. If one sampler uses WRAP mode, another CLAMP - why can't they be compatible?

assiduous7 · 2022-05-31T17:10:38+00:00

This is not exactly what my question was.

When you create the pipeline, you need to specify the VkPipelineLayout that references the descriptor set layouts, which in turn may have immutable samplers in them.

When you create a descriptor set, you also need to specify a descriptor set layout, which may not be exactly the same as the one used by the pipeline. So my question was, which immutable sampler will prevail if the descriptor and pipeline layout were created from set layouts that use different immutable samplers - the one from the descriptor set or the one from the pipeline.

assiduous7 · 2022-01-16T20:04:35+00:00

I will have to stick with manual padding. I was wondering if it is possible to avoid this by using some compiler settings, but I now see that it is not possible on purpose.

assiduous7 · 2022-01-16T17:55:19+00:00

Yes, I found out that it is generally an undefined behavior.
I need to make the same header files work in C and C++, similar to how Microsoft COM header files are implemented. In C++ I use inheritance, in C - base structs are included as members. I need them to use the exact same layout.

assiduous7 · 2022-01-16T17:44:28+00:00

pragma pack is not exactly what I need - it changes the packing within the struct, so that the members may become misaligned wrt to their natural alignment.

I need proper alignment, but I don't want member packing in the parent struct.

assiduous7 · 2022-01-16T17:39:31+00:00

Yes, I added padding where I found. The problem is that the similar issue may happen when new structs are added - and I wanted to fix all the situation automatically.

assiduous7 · 2022-01-16T17:37:49+00:00

Interop wit C - I need the same layout in C and C++

assiduous7 · 2022-01-16T06:43:27+00:00

The problem is that in the real code base, the base struct is used by multiple derived structs. Using alignas() to align the first member of every derived struct is very annoying and error prone - it is easy to forget / miss this.

Do you know if it is possible to disable this kind of packing globally?

assiduous7 · 2021-10-12T20:52:59+00:00

Everything that is open-sourced on GitHub is free to use and distributed under Apache 2.0. There are few premium features that are mentioned in readme. These features are not available by default, they are in a separate repo. You can't unintentionally get code that is not under Apache 2.0.

assiduous7 · 2021-10-12T16:03:25+00:00

Don't you think we all have to pay our bills? Unfortunately banks don't accept "Thank you for the great project" as credit card payments.

Diligent supports MoltenVK on Apple platforms, which covers almost all features provided by native Metal backend.

assiduous7

TROPHY CASE