It seems vulkan expose its protocol to the user. I really don’t want to write stype field for every struct. Besides, why there’s so many properties for device, can we group them together? For example, we can add some helper functions which get all the properties for users. So that they can write code easier. Most app using vulkan want such thing. I think the vulkan-hpp library helps a little, but that’s cpp. I think protocol is important just in the background, users need more apparently.
I think the designer forget the importance of the conveniency. Another example is wayland… This makes its user less.
You are welcome to write helper functions and offer them to the community…
modify: I packed replies in to this one.
The problem is that even if I write helper functions. There’s few people would use it, because it’s not official. If it’s not official, there would be tons of libraries implement the same thing. That is resource waste.
If you are using a phone, then it asks you to write stype when you want to make a call, what would you think? I just want to use vulkan to write graph app, and it should be as easy as I think.
A good way is like http, which you are using now, you don’t have to know about tcp/ip. The good thing about the network stack is that it gives you many layers to jump in. If you need more control, you can use tcp/ip instead of http. And http is also a layer, it’s part of the protocol. Of cause the designers of the network could ask users to write stype at first, but with time goes by, they choice not to. I think that’s why the internet becomes so welcome.
Yes, the user can write code use this library, and it’s very good protocol implementation. But it’s the pain in the ass. Sorry to complain.
By the way, it’s good design to develop multiple levels of protocols. Because protocol is confined by the reality of the hardware and something else, we can’t use one level protocol to write excellent and convinent code. That’s why there’s http, tcp, ip.
It’s OK to write your entire post in one post. You don’t have to break each paragraph up into its own separate post. And you don’t have to press “Reply” every time you think you’ve finished. You can wait a bit to make sure you’ve said all you want to say before pressing that button.
And if you want to add more, you can edit the post. In fact, this paragraph was a post-reply addition.
But they won’t do the same things. What counts as “convenience” for one user is kind of important for another.
Um, no it isn’t.
TCP and IP are separate because they do separate things. They have different jobs. One is about routing data packets from one place to a different place. The other is about ensuring the integrity of data being transported when it reaches its destination. TCP is not “more convenient” than IP; it’s doing a different job.
The reason for breaking this down into different layers is because people have different needs. Are data integrity checks integrated into the data itself? Then use UDP instead of TCP. Etc. This is only possible because IP does exactly and only one job: get data from point A to point B. If you integrated these functions, then you’d have to reinvent everything to do something slightly different.
If you’re going to analogize Vulkan to this, Vulkan is much closer to being just IP than anything else. It does one thing: interface with the graphics hardware. That’s it.
That’s not why Vulkan exists. If you want it to be easy to write a “graph app,” then you should use tools that make it easy to do so. That’s not what Vulkan is for.
Vulkan is a low-level tool for manipulating graphics hardware. That it’s one job. It doesn’t make it easy, because manipulating graphics hardware is not easy.
There are many graphical systems built on top of Vulkan that make interacting with graphics hardware easy. If Vulkan is too difficult, you can use those.
Yeah, so it there a standard group to do the second layer of the job? I think many people need the second layer which is built upon yours. If that’s the goal of vulkan, vulkan gets too much attention. It should be only known by the second layer designers. A lot of libraries shouldn’t use vulkan at all. By the way, compare to vulkan, other graphic framework is MUCH easier to be used. Now it’s understandable, that’s because they set their goal higher than vulkan.
Besides, if that’s the goal of vulkan, vulkan-hpp shouldn’t exist at all, maybe it’s time to delete it.
That depends on which frameworks. Vulkan has the distinction of covering the widest variety of hardware among all command-buffer-style APIs. Metal will never have to worry about running on non-Apple GPUs. D3D12 will never run on mobile GPUs and therefore need not concern itself with the vagaries of tile-based rendering. By contrast, Vulkan covers all GPUs and platforms; that coverage creates additional complexity.
Not the sType thing. That is a triviality next to the actual complexities of the API.
Vulkan-hpp is just a C++ wrapper around Vulkan. Saying it shouldn’t exist is like saying that Rust’s Vulkan interface should exist either. It doesn’t remove any complexity from the API. It functionally lives at the same level of operation; it’s just trivially more convenient in some respects.
And how widely Vulkan-hpp is used outside of hobbyist circles is debatable. I doubt serious game engines bother with it.
I think vulkan does a good job at what you say. There’s no doubt.
For vulkan-hpp we can use vulkan directly from cpp. So what you say about rust is no the same.
As you say: “It doesn’t remove any complexity from the API”.
Yes! That’s why few people use vulkan-hpp.
Having multiple layers of abstract doesn’t mean losing control of the lower layers. So vulkan can be better. Vulkan achieve the goal as it meant to be, but not in a good way. Adding more helper functions can make it better.
All in all, vulkan did a good job at what you said. But it can be better. But it didn’t.
The important problem is that there’s no standard group to do this job! The same thing happens in wayland too.
You can add a num ten times, or you can multiply it by ten. vulkan choice to add ten times… That’s funny because it achieves its job.
For the record, what makes internet great is content. Virtually all internet technologies are famously shit-tier. Including, and in particular, HTTP. If anything, it is a moral story on the importance of good foundations, since they are super hard to change later when massively adopted.
Not saying that they always do good with Vulkan. They do sometimes annoy me, and things sometimes suffer from typical ills of design-by-commitee approach. But it is certainly an improvement over OpenGL.
Anyway, it is not communism. Where things get less obvious how they should be implemented, multiple offerings can compete for your attention. Both Unreal and Unity can coexist, and you can decide for yourself which is a better abstraction.
Vulkan-Hpp, ignoring some cute parts, is more of a binding. It takes Vulkan and tries to make it fit into C++ idiosyncracies. Not an abstraction per se. BTW, oftentimes things are case of lacking features of a programming language itself, while any attempts to mitigate it are kinda desperate. Impossibility to reasonably preset sType is typical deficiency of C language. And e.g. that you can’t trivially get name of a type or enumerant as a string is a deficiency of C++ language. But some helper libraries are included in the official SDK.
What makes internet great is the convinency! If we have to write stypes in http, obviously there’re less people would use it, then the content will be suffered. I think what vulkan did is very important, and certainly it did a good job! But vulkan can be better, that’s also true. The reason stype is exist is because vulkan expose protocol to its user. Designing a protocol is hard! That’s why I say what they did is excellent. But the whole point of a library or a language is the convenience. Otherwise, you can type mechine code directly! So the reason why vulkan is exist is because writing graphics code is difficult or inconvenient. Now we have the same reason to improve it. I think C and C++ obviously have the ability to abstraction. What is lacking is the second layer of abstraction. Maybe it’s time for the comnunity to expend a little time on providing these things, so the end user can all benifit from it. And it’s official, so everybody save their time. This will attract more users to use vulkan, and vulkan can benifit from the increase of its user. You can’t leave the burdon to the engines like Unreal or Unity, they are not official, and there are tons of other libraries. The abstraction can be built before the engine code. Convenience is also IMPORTANT!
No, you can’t. In some cases, those details are entirely proprietary and are unavailable to most people. Even in cases where they’re not proprietary, they are implemented in fundamentally different ways across a variety of different hardware. Also, GPUs don’t belong to you; they belong to the operating system, and you maybe can access them if you ask nicely. Userland code is not allowed to just become a graphics driver.
It’s very bizarre that you’re comparing the task of writing a graphics driver to… setting a value in a struct to a particular value.
What are “these things”? The only specific “thing” you’ve brought up is sType, which is am annoyance at best.
Every few months or so, we get a random person coming to complain about how Vulkan is too hard to use and that it should be simpler and that it is the Khronos group’s job to make it simpler (even though such a simplification would live above the driver and thus wouldn’t need to be part of Vulkan itself). But more often than not, the issues they bring up are relatively minor issues or are things that need to be there to support different applications and/or hardware.
Gpu needs to provide it’s interface, so you CAN hard code to call them! Otherwice GPU wouldn’t exist, because they need to provide service. So is the operating system. Gpus don’t have to provide vulkan interface, but they have to provide a interface. Vulkan now is their good choice.
There’re many people to complain about the convenience, so the inconvenience is inarguable. And you choice to ignore…
Have you wrote robust code to graphics using vulkan by hand? I mean write them not see them. If you did, you know you have to write thousand lines of code at least to show a triangle. And it’s not fun to write it, if you don’t, you should give it a try.
No, you are naive. For example, I just internetted you without touching HTTP.
The reason sType exists outside pNext where it gets type pruned, is arguably dumb. But what is done is done. C++ has features to deal with it. C does not.
Official adoption has precedent. Vulkan-Hpp and VMA is now in the SDK. MoltenVK is now under umbrella of Khronos. Present, say, three independent implementations of these abstractions you claim everyone wastes their time with, and maybe the ideas can be pulled into one decent library.
Convenience is the least important aspect to people that are supposed to be engineers. What they ask engineers first is whether the bridge they are building will not crumble within 5 years. They don’t ask them whether they had fun making it. As for userbase, quality over quantity. We don’t need millions people making engines; we only need a couple of the best ones to do the bestest job possible for the rest of us.
PS: Vulkan is not an API to show a triangle. If everything you want is to show a triangle, then just draw one with like 10 lines of pure C++. It will be convenient as well as more performant.
I don’t know who is naive. We have http. But we don’t have the counterparts in vulkan. So it’s diffierent. I didn’t say protocol is not important. You actually didn’t understand what I was saying. What you say is like to say http is not important, because tcp/ip is great and important, and http shouldn’t exist at all.Engineers can write their own http. Or assemble language is good, we can use it to write any functionality, so we don’t need c.
Of cause stype can be hidden! What we can do with cpp, we can do with c. And in this case, we just need to wrap another layer. What a lousy excuse you are giving to me.
A lot of people complain about conveninence to you. And you choice not to hear it. The conveninence is important. You just don’t admit it. The whole point of a library or a language is about conveninence. And you think it’s not important.
Arguing this with you is a waste of time. Too arrogant you guys. By the way, you should write assemble language youself to program, don’t ask other people do it for you… I think you deserve it.
Oh my… I hope you feel better now.
1 Like
That’s kind of the opposite of your point. Yes, “we” can do the same things in C++ that “we” do in C, but in C it requires manual intervention. C++ constructors automate things like setting struct member variables to a value. C cannot do that; you have to explicitly set each member variable to a value.
So yes, a C program can do the same stuff a C++ program does. But it would be less convenient, because C is a less convenient language.
Disagreement does not mean that we don’t hear it. It means we disagree. It may also mean that their arguments are bad.
Not agreeing with your opinions does not mean we don’t think convenience is important. We just have other priorities. And this sType nonsense is so far down the priority list that it barely registers as a problem.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.