Vk1.1 is so obscure and difficult to use. vk1.3 has a “dynamic_state2” extension that enforces the implementation of the api. However, vk1.2x cannot run on the lower version of Win10, and its compatibility is too poor. Within five years, all mobile platforms can be replaced. Can the personal computer platform, hardware, and system be replaced?
An API VK like, should be able to use Win7 as long as it has a driver, but there is no driver. Finally, like dx12, “cross platform” crossed a lonely path.
Rhi, who currently does not have a good solution, likes a “differentiated” culture. I’m really tired.
Who is the true cross platform API? Currently, there may only be GLES from Angle.
Your post is so vague, non-specific, and internally conflicting that I dare say it’s very unlikely you’re going to get anything close to the answer you seek from what you’ve posted. That is, assuming you have a specific question.
But that’s not a problem Vulkan can fix. There’s nothing in Vulkan that prevents a driver maker from writing a Windows 7 driver for it. They simply don’t, because Win7 is an unsupported OS and they don’t want to support a codebase for an OS that is no longer supported.
That’s not a problem that Vulkan or the Khronos group can fix.
Also, I have no idea what the title of this thread has to do with the body of it. You mention NV_command_list in the title, but not in your question. Also, NV_command_list is not supported for OpenGL ES, so I don’t know why you brought it up.
Um, yes? Command buffers are not something that most non-NVIDIA hardware can handle within the limitations of still pretending to use OpenGL. NVIDIA’s hardware handles image layouts manually; most other hardware does not. Without support for image layout transitions (which would be completely foreign to OpenGL, and OpenGL doesn’t really have a good way to do that), any hardware that requires manually upkeep for image layouts would be unable to work with that API.
But it’s unclear what any of that has to do with your topic.