#1: is a managerial technique called “not my problem, not our problem, not our cost”. It is really called a hole in the requirements, and will become a thorn in everyone’s sides (both vendors and users) for the same reason Win32 is never going away.
You could use this logic against any API. You can point at any API and say, “well, it can’t do this, which I say is totally important and in the future, the lack of this will make the API a millstone around our necks”.
You’re basically saying that your design, your needs, your application is the future, and any API that isn’t quite doing things the way your design says they should be done is just living in a past that will eventually have to be ditched.
John Carmack famously said once that OpenGL implementations should have no shader limitations; that if a shader blew past limitations, the IHV should break the shader up into multiple shaders and just make it work as if it were one shader.
Now, we can clearly see from a modern perspective that this was a powerfully stupid request. Indeed, Vulkan goes in the exact opposite direction: less IHV code rather than more. But my point is that Carmack was talking about making OpenGL more future-proof. Just like you. You’re saying that the future looks like X, and Vulkan doesn’t look like that, so it better change to match.
But Carmack could not predict the future. Just like SGI back in 1992 could not predict the shader revolution. Just like so many other failed attempts to predict the future of APIs.
Why are your predictions any different?
Predicting the future keeps you from living in the present. If these really are problems, there is nothing that says they can’t be worked out. Vulkan already has built-in backwards-incompatibility (major releases are not required to have any compatibility requirements). If they need to make some serious changes, that can still be done.
#2: Nobody needs to use a completion port in the same sense that nobody needs to use a pipeline cache (yes, we use them).
“Completion ports” are not the only feature you’ve talked about in this thread. You’ve discussed automating layout transitions and queue ownership. You’ve discussed automating semaphore usage. Among other things. These unequivocally have costs for users who can manage these things themselves.
Also, any feature has a cost: the cost of its implementation. Even ignoring that “completion ports” are a platform-specific thing, implementers have to do whatever it takes to implement queues as “completion ports”. I know nothing about these things, but I can’t imagine it would be particularly trivial for them to implement them.
So the time IHVs spend on implementing, debugging, and maintaining them is time not spent on implementing, debugging, and maintaining something else.
It has been staring me in the face for a while as: “This can be done, it must be done”, so I thought it might not require too much explanation, that and I have to be careful.
The whole concept of non-POD image layout is annoying to me, since the spec offers no guarantee, and with a software renderer its just a re-arrangment of plain data that can be moved around freely. It is hard to imagine it being otherwise, but I can’t rely on intuition.
As you might draw from my writing, my fried brain is kinda all over the place, and has been for an entire year.
As you might imagine, it makes it difficult to have a productive discussion when you yourself cannot effectively articulate what you want. You just spent three paragraphs responding to my comment. And yet in all of that… you never answered my question.
I don’t know what a “POD image layout” is. However, from various descriptions, I’m guessing you’re talking about this.
Personally? I don’t see that as an issue of high moment. That is, I agree that it would be nice to be able to shift image data around in memory with simple memcpy’s and create new VkImages from them. But the inability to do this not really significantly impeding the majority of Vulkan users.
There are a lot more issues of greater importance than solving this one. I mean, it’s not like you can’t copy image data around. You just have to use a slightly inconvenient way to do it, issuing multiple commands and so forth.
As for how to solve it? Well first, you have to acknowledge the possibility that a particular image format may be more than just its data. As such, you have to query whether or not the implementation allows a particular VkImage is “relocatable” (“POD” is really the wrong term). This would be a “format feature”, but it is only available for swizzled images.
Next, when you create such an image, you have to create it as a relocatable image (that is, you have the intent to relocate it). After that, it should be a simple matter of binding it to the appropriate location in memory. And of course changing the memory aliasing rules.
We have to code against the specification alone, and whatever it leaves out, if that makes sense. Basically, we assume the most asinine device possible (and within reason) that still meets the specification.[…]So, as far as the spec is concerned, we are following convention - “a device has N queue families…” and the “…” is where it drops into this hole I’m talking about. This is where we’d have to fill it in with information outside the specification.
That is not a “hole in the specification”. That is your own personal paranoia about some possibility that has not happened and, as far as you know, will never happen.
There is nothing that “makes sense” about a device with “48 different families all generated with random capabilities”.
Vulkan should not be blamed for your choices. Other application developers don’t feel the need to do this; why do you? To be “future proof”? To be adaptive to some unknown and unknowable hardware that doesn’t exist yet?