Jump to content
  • Advertisement
Sign in to follow this  
Dexario

Vulkan How do you go about abstracting Vulkan's verbosity ?

This topic is 618 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi. I'm currently building a small Vulkan engine, I find one of the most challenging things to do is abstracting, simplifying the Vulkan interface, especially the very long structs (ie Vk---CreateInfo). You quickly end up with hundreds of lines of just filling structs.

To simplify that, I thought of wrapping the most important structs in classes with default values and helper functions, as shown in the following example:

class GraphicsPipeline
{
public:
	GraphicsPipeline();

	void create(const VkDevice* device);
	void dealloc(const VkDevice* device);
	VkPipeline getPipeline();

	void resetToDefault();

	...
	Some helper functions
	...

	VkGraphicsPipelineCreateInfo pipelineCreateInfo;
private:
	VkPipeline m_pipeline;
	...
};

The resetToDefault() function is mainly where the abstraction takes place: it fills the pipelineCreateInfo attribute with default values.

Since the pipelineCreateInfo attribute is public, it allows the programmer to change anything he wants within the structure (in theory) and expand upon the default values.

 

This all works great in theory. Unfortunately, there are a few problems with this:

-The VkGraphicsPipelineCreateInfo struct contains pointers to constant structs, therefore forbidding any modification.

        This means it is impossible to do that:

      GraphicsPipeline pipeline;
      pipeline.pipelineCreateInfo.pRasterizationState->polygonMode = VK_POLYGON_MODE_LINE 

         This is impossible since VkGraphicsPipelineCreateInfo::pRasterizationState is a pointer to a const:

      const VkPipelineRasterizationStateCreateInfo*    pRasterizationState;

-I may be wrong about that but I feel these Vk---CreateInfo structs are made for what I would call a "temporary instanciation". What makes me say that is the fact the structs contain so much pointers; at first it might not seem like a big deal but I realized it was a problem when creating my wrapper class: if the programmer wants to access any of the pipelineCreateInfo's pointers, they have to have been dynamically allocated before they get accessed. This means that in resetToDefault(), I would need to instanciate EVERY pointer and then recursively instanciate every pointer of the ones I just allocated and it quickly gets very complicated, even impossible. This is without thinking about deallocating everything after (though you could use a std::unique_ptr<>). This makes it very complicated to create a VkGraphicsPipelineCreateInfo attribute which can be filled in at different times.

 

This is why I come to you guys: How do you go about abstracting Vulkan's verbosity ? or Any ideas of how to simplify Vulkan's interface ? or How to implement Vulkan in an Engine ?

 

 

Share this post


Link to post
Share on other sites
Advertisement
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!