The Still New What Did You Last Do Thread

[wildweasel]

Alright, my opinion only matters to me, then.

[yum13241]

Well I'm not saying you're wrong or I'm right, at the end of the day everyone has a right to an opinion. An opinion is just that. An opinion. Not fact. (I did state some facts though) Don't be sad!

[Rachael]

Alright, my opinion only matters to me, then.

Hell no! I for one am glad you gave that recommendation, it's something for me to look into later on. So, thank you.

[InsanityBringer]

So, while descriptors are still warm on the brain, I do have a question about pipeline compatibility in Vulkan.. So I have a bunch of pipeline layouts that are all set up such that the first set is a single uniform buffer object which contains the camera's projection and modelview matrices, and the ones further down the set list are usually combined image samplers for texture inputs, or SSBOs with dynamic offsets for holding additional per-instance data. The way I understood pipeline compatibility is that if I bound a pipeline that used another layout, that UBO at set 0 would be undisturbed and I didn't have to rebind it, and indeed, the result is correct if I don't on my AMD card. But the validation layers don't like it when I don't, and therefore I have a large amount of redundant rebinds of the projection+modelview block descriptor set. Is there something obvious I'm missing here?

[Graf Zahl]

If the validation layers complain you are relying on undefined behavior and it may break at any time on any other driever.
There may be hardware that cannot do what you expect and must create a completely new internal object for it that then does not have your data anymore.

Simple as that.

[dpJudas]

I believe InsanityBringer is talking about the Pipeline Layout Compatibility which states that you do not need to rebind a descriptor set if the pipelines agree on how the descriptor sets looks like. The vulkan backend does not rebind the descriptor sets, but then the vulkan backend also only uses one pipeline layout for everything.

If the validation layer is complaining then I'm sure you are missing something though. Like Graf says, you can't just ignore validation error since it is very unlikely it is wrong. Are you absolutely sure the shared part of the pipeline layout is identical? Keep in mind that if you bind any pipeline that doesn't agree on the layout then it will be disturbed, forcing you to rebind index 0 if that other pipeline didn't use the same layout. I also believe the bind is only persistent within one command buffer, so you have to at least bind it once for each frame (or more, depending on how many command buffers you have).

[InsanityBringer]

Ah, the entirety of the state becoming undefined once a incompatible pipeline is bound seems to be the part of the puzzle I was missing, thank you. I think I might have to rethink my data some if I want to clean up binding, though atm performance isn't a problem as it runs reasonably fast even on my older card.

I think I got confused since a lot of sources talk about keeping data that rarely changes at the lower set numbers whereas the higher set numbers hold data that changes more frequently, but in retrospect they were probably talking about draws within the same pipeline layout.

[dpJudas]

I think I got confused since a lot of sources talk about keeping data that rarely changes at the lower set numbers whereas the higher set numbers hold data that changes more frequently, but in retrospect they were probably talking about draws within the same pipeline layout.

No, what I meant was that you must be doing something wrong with the bind. Either that you are binding a pipeline that indeed does not have an identical slot 0 descriptor set layout, or that you forgot to bind it at minimum once per command buffer.

I updated my zvulkan example to do what you described and I get no errors from the validation layer. Notice how in this example the pipeline layout for the two pipelines aren't the same at all, except that they both agree that slot 0 should be the uniformSetLayout descriptor set layout.

[InsanityBringer]

I am genuinely lost, then. I've gone over the code many times, and I cannot find where the life of me the incompatibility could be. Every pipeline layout I'm using ATM (I have 5 of them) has the exact same descriptor set layout at slot 0 in their array of descriptor set layouts, and it seemingly works on my hardware, but the validation layers just aren't having it. Maybe it's just a weird side effect of the more "unusual" decisions I've made? (using secondary command buffers and dynamic rendering). In the off chance that's throwing off the validation I am planning on undoing both of those decisions (AMD apparently warns against using secondary command buffers at all, and static render passes ultimately are going to make more sense since I'm planning on adding a post-process layer for underwater screen warping) so maybe this is a good chance to make those changes, but other than that I honestly cannot tell, looking at your sample and looking at the spec, where I'm going wrong. The binds are all local to their secondary command buffer, I'm sure of that at least.

The only thing the pipeline layouts vary on is what the set layouts beyond 0 are and their push constant ranges. I do want to post my code for this, but it's a bit messy ATM since I just developed it out of my local Quake 2 project. That, and vk_pipeline_data.h and vk_pipeline.cpp are both waay too complicated and annoying to navigate.

edit: wait, if the problem is elsewhere, how is it able to validate that things are correct when I do rebind? None of this makes any sense, but I'm now tearing out the secondary command buffers since they make no sense here.

edit 2: I've ruled it out being something related to the usage of those two features. your example code runs fine without flagging anything, and I went ahead and made the modifications to use render passes and got rid of the secondary command buffers, since right now's as good a time as any to perform that refactoring. And yeah, I'm so fucking lost. I have no clue whatsoever what's going on, it would be nice if the validation layers could provide more information here. RenderDoc doesn't have any objections to my setup, AMD's implementation doesn't have any objections, and I've chewed through tons of code, comparing it to your sample, and I can't figure out where it's diverging. This is so unbelievably frustrating I don't know where to begin trying to fix it. I've done everything I can at this point to rule it out being a weird bug in the validation layers, but if it was, someone surely would have noticed by now.

and after all that frustration, I have discovered the cause of the validation messages is the push constant ranges. Apparently not having push constant pipeline compatibility completely invalidates pipeline compatibility, at least in the eyes of the validation layer. I changed all my shaders to use the same range (4 floats worth of data visible to both the vertex and fragment shader), and it suddenly started working. I'll be honest, I'm having trouble finding anything in the spec that confirms this, but i've already demonstrated that I'm awful at spec reading so I'm sure it's there somewhere.

[dpJudas]

I completely missed the detail about the push constants disturbing the descriptor sets as well. It does say it at the very end of the first paragraph in the link I provided: "Two pipeline layouts are defined to be “compatible for set N” if they were created with identically defined descriptor set layouts for sets zero through N ... AND if they were created with IDENTICAL push constant ranges".

[InsanityBringer]

I'm really salty that I managed to overlook that multiple times when trying to figure out what's going on. I guess the biggest lesson I've learned is to become really freaking good at spec lawyering if I want to excel with Vulkan. I think I just shut out the idea since the concept of pipeline layout compatibility and compatibility for push constants was introduced somewhat separately.

I'm a little curious why they chose to write it that way, since some testing on other implementations seems to suggest things remain even when binding a pipeline with incompatible push constant ranges, but it's not hard for me to match the spec here, so no real problem. (I may have also reverted to my dynamic rendering code since I realized that due to the interface Quake 2 exposed, creating render passes that would account for all situations would be slightly annoying. I'll probably eat a minor perf penalty with it writing out the framebuffer for warp post-processing, but how much does it matter when my renderer can get hundreds of FPS on a modest card)

[dpJudas]

The spec is a total nightmare to read. Only tip I really have there is that if you inspect the page (press F12) and then add a ".sidebarblock { display: none !important; }" rule then it gets a bit easier to read. The same thing applies to the validation layer errors - here I have a filter in ZVulkan that removes the 'the spec says' stuff because it does more damage than good. The specific details of validation is no good is the overall description of things are lost in the process.

Like most modern documentation the javascript driving the docs is just terrible. It is really sad that HTML Help from the 90's was the pinnacle of documentation when it comes to browsing stuff with almost everything being a step down since then. I could never have learned the Win32 API today the way you have to browse it. Same thing with a lot of other stuff - like you can look up a specific command in vulkan, but then from there you can't browse around to related info. Too bad it is too unsexy a subject for anyone to really care about improving docs.

About why they wrote it that way, maybe they figured there could be a theoretical situation where it become problematic. Or there could be a mobile vendor that couldn't support it otherwise. There's a lot of rules in the spec that are effective no-ops in the drivers, which is why you absolutely have to use the validation layer always while developing for vulkan.

[InsanityBringer]

it's now happened twice while working on ref_vk
But wow why did it take ~6 years to realize there's a problem here and offer some sort of solution for it in extensions that aren't even KHR extensions? Absolutely beautiful. I was wondering how I was supposed to synchronize this when changing the vsync status in ref_vk, I ended up trying to brute force it with a vkDeviceWaitIdle which seems to work but doesn't feel right at all.

man sync's been a pain in general with regards to the swapchain.. To present the framebuffer the queue submit is set to signal a semaphore that the present code waits on, exactly as it's setup in the khronos sync samples, but OBS didn't like that until I added a cvar to do a fence wait between rendering and present. I might be doing something wrong, then.

[dpJudas]

Swapchains in vulkan is a real pain that's for sure. The bare minimum amount of semaphores and fences you can get away with is what GZDoom and the ZVulkan example is using.

I highly recommend you have one function that submits your current buffers in a systematic way. In GZDoom I have up to two open command buffers at any given time: transfer and draw. The idea here is that transfer is always submitted before draw, ensuring that upload commands and such will not require additional pipeline barriers to be set up in the command buffer used for drawing (since you can't do that with an open render pass). The submit function submits both as a group - either for present to the swap chain, or as a "glFinish". This allows me to not use vkDeviceWaitIdle.

By the way, if you think the general swapchain extension is hell, then try use the exclusive full screen extensions. That's just pure horror.

[yum13241]

Exclusive Fullscreen has basically no advantages these days. All it does is make it annoying to alt + tab out of and if game res != Monitor native res then if the game crashes you could be stuck at a low res. If chocolate doom used exclusive Fullscreen and the game crashed you'd be stuck at 640x480 or even worse, 320x200.


It might give an extra performance boost but exclusive Fullscreen in ogl is a hack anyway, ask Graf.