In Directx 11 resources load faster.
In Vulkan API i load 5 textures and 5 meshes 4 seconds.
Vulkan prehistoric api ? 
That’s probably a mistake in the way you load them in vulkan. For example using the wrong memory for the staging buffer; mapped device local memory is slow to write to for the CPU, prefer a host local staging buffer and a copy.
I do for this example https://github.com/SaschaWillems/Vulkan/blob/master/triangle/triangle.cpp
I create VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT memory and buffer(sharingMode = VK_SHARING_MODE_EXCLUSIVE and usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT) then load mesh in memory. Then create memory and buffer(usage = VK_BUFFER_USAGE_VERTEX_BUFFER_BIT + VK_BUFFER_USAGE_STORAGE_BUFFER_BIT+VK_BUFFER_USAGE_TRANSFER_DST_BIT) VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
Then copy from VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT to VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT memory mesh.
And rendering mesh from VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT memory.
How do faster ?
check which part is the slowest. (I’m guessing loading the mesh into memory)
The staging buffer (host visible) should preferably not have device local and should preferably have host cached.
I check.
My meshes (five) load one sec(in this time i do init Vulkan and load 5 meshes), but 5 textures load 3 seconds.
This is crutch Vulkan API.
Why Vulkan not have function LoadTexture ?
It was so hard to do for Khronos ?
Once again please add some details. What library are you using to load the textures? What size are they? How many mip levels, layers? Are you running with debug on and off? How do you measure performance?
I don’t think upload or buffer copy is the bottleneck with so few assets.
But in general: You’re probably doing a single allocation for each mesh and texture (like my examples). You shouldn’t do that in an application that loads lots of assets. Instead allocate in big chunks like this blog post by AMD describes.
What library are you using to load the textures?
Not using any library.
Yes i allocating memory for new texture.
Ok for CPU_access memory i might do one time alloc. mem.
But for GPU memory whear store textures i must do new allocations.
One texture must have one owner memory.
[QUOTE=Ronniko;40743]But for GPU memory whear store textures i must do new allocations.
One texture must have one owner memory.[/QUOTE]
That’s not true. You’re not forced to do a separate Vulkan memory allocation for each texture, memory management is up to you. If you’re using lots of textures, do one big allocate from device local heap and then just sub-allocate for each texture from that chunk. It’s a bit more work as you’d have to write your own suballocator (that’s what the callbacks in Vulkan’s allocation functions are for), but it’s worth the effort if you want to do more than just simple examples.
Sascha Willems write example
How right load many textures.
I two months ago sad to you.
Doing single allocations is not wrong. It’s just slower…
It’s on the planned list of examples for my repo. My spare time is very limited right now, so no ETA on that.
But it’s actually pretty simple, and I’,m sure that there are examples on this from other people.
This is crutch Vulkan API.
Why Vulkan not have function LoadTexture ?
It was so hard to do for Khronos ?
Have you considered that Vulkan just isn’t for you?
From the pattern of your questions, it seems very clear that you don’t want to use a low-level, explicit API. What you really want to use is Direct3D 11 or OpenGL. You want to use an API with training wheels, one that does things for you, one that has simple features that work simply, one that stops you from making mistakes and holds your hand when you walk across the street. That’s fine; I’ve got nothing against that.
But that API is not Vulkan.
It is foolish to expect behavior out of Vulkan when that behavior is explicitly what Vulkan was designed to avoid. Vulkan doesn’t have a simple LoadTexture function because it isn’t supposed to. Such a function would manage memory, and half the point of Vulkan is that you manage memory, not the API.
Vulkan is for people who want to manage memory allocations themselves. Vulkan is for people who want to manage dependencies manually, who want to be able to get down into the guts of such things. If that’s not you, then it would probably save everyone lots of time and aggravation if you just moved on to another API.
If you want APIs with LoadTexture functions, they already exist; feel free to go use those APIs. But if you want to use a low-level API like Vulkan, then you need to approach the API on Vulkan’s terms, not by constantly comparing it to some other API and wishing it had convenience features.
Vulkan is meant to be convenient. It is meant to be powerful and explicit.
@AR I would recommend you not to give unsolicited advice (of the type “go use easier X instead”). It rarely ever causes reflection or change of mind of the recipient. It is only designed to anger them.
Anyway, for the sake of derailing threads and writing off-topic :D, I wanted to respond to some claims you made.
I never felt particulary with training wheels in OpenGL. Vulkan have some potential with the layers (though OGL added Debug context too - but that is at the mercy of the vendor).
Nor that it is particulary simple (considering the cumulative amount of extensions too). Some things actually are positively simpler in Vulkan.
The point with LoadTexture() (and similar) is it is redundant to more specific functions in Vulkan (as Transformation stack bacame redundant in OGL3). It can be simply exported to some convenience library and does not need to bloat Vulkan itself. There’s nothing necessarily wrong with wanting convenience in Vulkan - it’s just not part of the core Vulkan API, but perhaps it is elsewhere in some tools library.
It may anger them, but it is not “designed to” do so. I’m trying to educate him, because he’s clearly expecting the API to provide features that it’s not going to. And he’s becoming increasingly frustrated by that, as evidenced by his constant refrain of “API X did it better!” every time he encounters a problem.
It seems abundantly clear that he’s expecting a hammer to be able to drive screws. I’m telling him that the hammer isn’t built for that, and he’d be much better off using a screwdriver. A hammer isn’t bad because it’s a hammer; it’s using it wrongly that’s the problem.
Have you crashed your GPU more times with OpenGL or Vulkan? How many times have you read from a texture you just rendered to without even thinking about what was needed to make that work? How many times have you accidentally uploaded texture data in an improper format and just had everything work anyway?
You may not have felt those training wheels, but they were nevertheless there.
The things that are simpler in Vulkan are primarily things where OpenGL:
-
had many ways of doing things to no positive effect: vertex specification, the massive number of rendering commands
-
used the wrong abstraction: VAOs, non-block uniforms as per-program state
-
did something flat-out boneheaded:
gl_InstanceID, all texture creation pre-texture_storage, bind-to-edit -
made you work really hard to get reasonable performance: tile-based renderers and FBOs, buffer streaming, asynchronous stuff
Then why use Vulkan directly at all? The whole point of Vulkan is that it allows you to have explicit control, and you use it if you need explicit control. Using Vulkan through “some tools library” that allocates memory for you is throwing away the point of the API.
I do admit that there is some space where some helper library could comfortably live between the user and Vulkan. See the other thread for examples.
But something like LoadTexture would not be among them. That process requires multiple things that a good user of Vulkan wants to have direct control over: the allocation of the texture’s memory, the allocation of the staging buffer (because you may wish to reuse it), performing the transfer operation itself, and synchronizing operations with that transfer. Any simplistic LoadTexture function would have to handle all of those.
Oh, and the GL transform stack was not removed because it was “redundant.” It was removed because it was pointless bloat that did something you could easily do yourself. The point of the 3.0 deprecation-and-removal was to ditch pretty much anything that you could do yourself without losing performance.
a good user of Vulkan wants to have direct control over: the allocation of the texture’s memory, the allocation of the staging buffer
Why good users not write owner Vulkan Driver ?