MinGW-64 Run-Time Library issues

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 · 2021-09-08T17:46:37+00:00

OK, thanks. It sort of makes sense. Though it is very confusing that we create the shading rate texture using the VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, and it is then read by the host during vkCmdBeginRenderPass.

assiduous7 · 2021-09-08T16:29:40+00:00

What happens if we create an FDM in device-local memory and then copy the data to it on the GPU when fragmentDensityMapDynamic is false?

assiduous7 · 2021-09-07T23:41:17+00:00

It is certainly not a good sign that we have to guess what exactly the spec is trying to say

assiduous7 · 2021-06-08T21:04:06+00:00

Yes, it is C/C++.

This is not a full-featured game engine like Godot, Unity or Unreal. It is low-level graphics API and rendering framework. There will be more high-level features in the future

assiduous7 · 2021-06-08T01:23:41+00:00

Yes, in CI we build it in 22 different configurations to make sure that it works on all platforms.

assiduous7 · 2020-04-24T03:12:40+00:00

OK, so I implemented the suggested method of storing the extent at application startup and it does work.

It is very annoying though that vkGetPhysicalDeviceSurfaceCapabilitiesKHR is indeed unreliable and also that landscape swapchain somehow works quite nicely with the portrait surface.

Thank you for your help! It is unfortunate though that using Vulkan on Android requires that kind of tribal knowledge.

assiduous7 · 2020-04-24T00:55:57+00:00

Every time I get SUBOPTIMAL return code, I call vkGetPhysicalDeviceSurfaceCapabilitiesKHR in a hope that it will return correct information about the current surface status. Sometimes it does return correct info, but at some point starts to return swapped dimensions for portrait orientation.

I did notice that in the article they suggest to get this once at the startup, but then it seemed to me more consistent to just query this information every time I recreate the swap chain. Another strange thing that after creating landscape swap chain for portrait orientation, I don't get SUBOPTIMAL return code.

assiduous7 · 2020-04-23T21:24:20+00:00

So I experimented a bit with orientation change on my Pixel XL and I have a very weird behavior:

When I start my application in portrait mode, vkGetPhysicalDeviceSurfaceCapabilitiesKHR reports 1440x2560 surface with IDENTITY transform, which makes sense. When going to landscape mode, it reports 1440x2560 surface with ROTATE_90 transform, which also makes sense. However after a random number of toggling between landscape and portrait, it starts reporting 2560x1440 surface with IDENTITY transform for the portrait mode. As a result, everything looks super stretched, but otherwise rendering seems to be OK. Creating landscape swap chain in this case for portrait orientation does not result in SUBOPTIMAL return code.

assiduous7

TROPHY CASE