Hello guys,
i just want to share my bachelor-thesis about the “design and implementation of a vulkan-based rendering-engine” in GERMAN.
Link: Dropbox - File Deleted
P.S.: I am new to graphics-programming and working with vulkan since april, so its possible that i completely missunderstood some things therefore i wont make any promise that everything is correct.
But i think it gives very nice and detailed explanations about the concepts of vulkan and how they work and i wish i would have such a paper when i started learning vulkan
I am not pretty sure since I do not speak german at all. However, in your page 25, you are talking about HOST_WRITE_BIT. But you do not mention anywhere the event (I am not speaking german I told you).
HOST_WRITE_BIT is for when the commandBuffer will wait for an event from the host.
Why?
The specs are clear :
For host writes to be seen by subsequent command buffer operations, a pipeline barrier from a source of VK_ACCESS_HOST_WRITE_BIT and VK_PIPELINE_STAGE_HOST_BIT to a destination of the relevant device pipeline stages and access types must be performed. Note that such a barrier is performed implicitly upon each command buffer submission, so an explicit barrier is only rarely needed (e.g. if a command buffer waits upon an event signaled by the host, where the host wrote some data after submission)
If you do not use an even, you do not need to use a host barrier.
Page 30. You are talking about subpass dependencies between Presentation engine and work submission I guess.
According to me, you do not need such dependies because semaphore will make write available / visible and ensure that the presentation has finished.
Also, you are using setImageLayout. I am curious to see how you use the pipelineBarrier in these cases. If you are using a memory barrier from TOP_OF_PIPE to TOP_OF_PIPE like I see in many websites, you are probably wrong .
I wish technical universities would encourage use of the lingua franca.
Also wish they would not insist upon the medieval written report with poor typography and other nonsensical formal requirements.
Could be useful to wider audience that way…
[QUOTE=qnoper;41419]I am not pretty sure since I do not speak german at all. However, in your page 25, you are talking about HOST_WRITE_BIT. But you do not mention anywhere the event (I am not speaking german I told you).
HOST_WRITE_BIT is for when the commandBuffer will wait for an event from the host.
Why?
The specs are clear :
If you do not use an even, you do not need to use a host barrier.
[/QUOTE]
Yes you are right, the example itself is wrong. I just made it to demonstrate this “complicated execution/memory dependency thing”.
Not quite. I talking about subpass dependencies between several render-passes to ensure, that the writing to an texture has been finished before someone else will sample from it (e.g. rendering the shadowmap and the following sampling in a FS).
At the end of your thesis, you are using a function which is named setImageLayout. I just say that a TOP_OF_PIPE to TOP_OF_PIPE barrier may be wrong. I do not know what your function look
It is not wrong : it may be wrong. It depends on your case.
For example, if you want to transition layout from PREINITIALIZED, putting a barrier with a srcStage at TOP and srcAccess at 0 is, IMHO the best solution (even if the layer will tell you that you are wrong, it is the validation layers that are wrong and it will be solved).
However, if you want to transition from TRANSFER_DST it is not good because at TOP_STAGE, the transfer stage is not completed, and issue a memory barrier at TOP_OF_STAGE is, IMHO, meaningless since TOP_OF_STAGE does not access the memory.
I wrote that for vulkan-tutorial here
And I wrote my understanding from execution barrier and memory barrier here
Yea i have read your blogpost and the references on that. I did understand Pipeline-Barriers and the whole execution thing, but using them correctly is really difficult in my opinion. Btw i tried a bunch of combinations for the srcStage and dstStage for all my pipeline-barriers and it feels like they just do nothing ._. nothing changes, not a slight performance difference or that.
Actually, it is not because you did the thing in the wrong way in Vulkan that it will do not work ^^, it is the problem, there is no implementation that follows EXACTLY what specification said and no other things. That’s it, we can not know if we do EXACTLY the good thing or not ^^.
Maybe Alfonse Reinheart can confirm (or inverse) what I said?
Memory accesses using the set of access types in srcAccessMask performed in pipeline stages in srcStageMask by the first set of commands must complete and be available to later commands.
.
To me it is clear that TOP_OF_PIPE is not a good thing talking about memory barrier.
Critique, that I can always do!. I don’t speak german either but scanned some of the code listings.
Some grammarish problems in the comments (e.g. lowercase I, i.e. instead of e.g., aswell, bind vs bound, missing words)
Lot of copied figures from Khoronos presentations. Should be well citated.
In VkApplicationInfo
3) the app and engine versions can have custom versioning scheme. It does not necessarily make sense to use VK_MAKE_VERSION.
4) The engine (the app name too) can be NULL, so little point to have engine named "No Engine".
In C++ should use the ugly casts e.g. static_cast. The thinking is if ever was needed to make the code robust (e.g. check if the vector size fits in the uint32_t) then it is easier to search for the ugly casts.
In initLayersAndExtensions():
6) You don’t seem to have DEF_LUNARG_VALIDATION_LAYER_NAME explained. I think it’s worth mentioning and "standard_validation" should be part of it.
7) It is misleading that “device layers should not be used”. In the new spec version they cannot be used (the variables are ignored). But the spec also says you should pretend as if they still existed (for backwards compatibility). At least deviceLayerNames = instanceLayerNames; should be done.
In createDevice():
8) Should not necessarily use gpu0. Might be integrated graphics card or what not, and user wouldn’t like that
9) The VkDeviceQueueCreateInfos are missing zero initialization (so probably have uninitialized pNexts and flags).
10) 0.0 priorities look suspicious. I would prefer 1.0 (highest priority) as the default. Shouldn’t matter though
11) No VkResult
12) Could have fake VkDevice declaration (as you do in some other exampes)
In createSwapchain()
13) It is possible to destroy VK_NULL_HANDLE – the if is redundant. But I have drivers that crash with that. So probably worth mentioning that it is a workaround.
14) setSwapchainExtent2D() little reason to take Window. On most platforms you are supposed to use currentExtent. Except one – if that is for its purposes, then that is probably worth to mention there.
15) There is an argument for using minImages+1 images if possible (e.g. cube demo does so).
16) I have a spec GH Issue on that but until that’s resolved you should check your compositeAlpha wheter it is supported. (Layer count too but that’s perhaps too pedantic.)
17) It says “have to supply oldSwapchain”. Technically that’s not true.
presentComplete name is misleading. Because the presentation may not be even completed.
while( true ) but no break
From the spec I am not so convinced you can omit the renderCompleteSem as you claim.
VkSubpassDependencysrc=BOTTOM seems weird. Should perhaps be COLOR_ATTACHMENT_OUTPUT (chained with the assumed semaphore wait flags before)
In the frambufer example comments it says “MUST not” that’s probably a mistake.
In VkClearValues for alpha there is 0.0. That’s a bit unusual.
Says “store in command buffer”. The proper term is “record”.
Pipeline example says “All shaders used in this pipeline.” Not sure what is meant by that statement.
.
