qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-12-18 16:42:07 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/include/QF/Vulkan/render.h

263 lines
6.7 KiB
C
Raw Normal View History

[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
#ifndef __QF_Vulkan_render_h
#define __QF_Vulkan_render_h
#ifndef VK_NO_PROTOTYPES
#define VK_NO_PROTOTYPES
#endif
#include <vulkan/vulkan.h>
[vulkan] Create a render context This gets an empty (no tasks or pipelines connected) render context initialized and available for other subsystems to register their task functions. Nothing is using it yet, but the test parse of rp_main_def fails gracefully (needs those tasks).
2023-02-13 08:45:36 +00:00
#include "QF/cexpr.h"
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
#include "QF/simd/types.h"
[vulkan] move qfv_output_t to render.h The plan is qf_renderpass.h (and vulkan_renderpass.c) will eventually disappear as they get absorbed by render.[ch].
2023-02-19 03:31:40 +00:00
typedef struct qfv_output_s {
VkExtent2D extent;
VkImage image; // only if owned
VkImageView view;
VkFormat format;
uint32_t frames;
VkImageView *view_list; // per frame
VkImageLayout finalLayout;
} qfv_output_t;
[vulkan] Use references for views and pipelines I'm pretty sure I don't want to require views to be created and pipelines to be parsed just to parse the render pass info.
2023-02-11 17:40:52 +00:00
typedef struct qfv_reference_s {
const char *name;
int line;
} qfv_reference_t;
[vulkan] Parse in descriptor set layouts For now, just their create info is parsed, but they will be created on demand. Most importantly, they are named for ease of use in pipeline layouts.
2023-02-26 11:54:11 +00:00
typedef struct qfv_descriptorsetinfo_s {
const char *name;
VkDescriptorSetLayoutCreateFlags flags;
uint32_t num_bindings;
VkDescriptorSetLayoutBinding *bindings;
VkDescriptorSetLayout setLayout;
} qfv_descriptorsetinfo_t;
[vulkan] Create render passes and pipelines There are many issues (in particular, shutdown doesn't clean up properly), but creation passes validation.
2023-02-26 18:00:14 +00:00
typedef struct qfv_layoutinfo_s {
const char *name;
uint32_t num_sets;
qfv_reference_t *sets;
uint32_t num_ranges;
VkPushConstantRange *ranges;
VkPipelineLayout layout;
} qfv_layoutinfo_t;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
typedef struct qfv_imageinfo_s {
const char *name;
VkImageCreateFlags flags;
VkImageType imageType;
VkFormat format;
VkExtent3D extent;
uint32_t mipLevels;
uint32_t arrayLayers;
VkSampleCountFlagBits samples;
VkImageTiling tiling;
VkImageUsageFlags usage;
[vulkan] Get render info parsing partially working A bunch of missed struct members, incorrect parse types, and some logic errors in the parse setup. Still not working due to problems with vectors from plist string references and some other errors, but getting there.
2023-02-10 10:45:02 +00:00
VkImageLayout initialLayout;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
} qfv_imageinfo_t;
typedef struct qfv_imageviewinfo_s {
const char *name;
VkImageViewCreateFlags flags;
[vulkan] Create the render images and views And tear them down again on shutdown. The images and views are in a qfv_resource_t block, making their management much easier.
2023-02-19 03:53:02 +00:00
qfv_reference_t image;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
VkImageViewType viewType;
VkFormat format;
VkComponentMapping components;
VkImageSubresourceRange subresourceRange;
} qfv_imageviewinfo_t;
typedef struct qfv_dependencymask_s {
VkPipelineStageFlags stage;
VkAccessFlags access;
} qfv_dependencymask_t;
typedef struct qfv_dependencyinfo_s {
const char *name;
qfv_dependencymask_t src;
qfv_dependencymask_t dst;
VkDependencyFlags flags;
} qfv_dependencyinfo_t;
typedef struct qfv_attachmentinfo_s {
const char *name;
VkAttachmentDescriptionFlags flags;
VkFormat format;
VkSampleCountFlagBits samples;
VkAttachmentLoadOp loadOp;
VkAttachmentStoreOp storeOp;
VkAttachmentLoadOp stencilLoadOp;
VkAttachmentStoreOp stencilStoreOp;
VkImageLayout initialLayout;
VkImageLayout finalLayout;
[vulkan] Get render info parsing partially working A bunch of missed struct members, incorrect parse types, and some logic errors in the parse setup. Still not working due to problems with vectors from plist string references and some other errors, but getting there.
2023-02-10 10:45:02 +00:00
VkClearValue clearValue;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
} qfv_attachmentinfo_t;
typedef struct qfv_taskinfo_s {
[vulkan] Create a render context This gets an empty (no tasks or pipelines connected) render context initialized and available for other subsystems to register their task functions. Nothing is using it yet, but the test parse of rp_main_def fails gracefully (needs those tasks).
2023-02-13 08:45:36 +00:00
exprfunc_t *func;
const exprval_t **params;
[vulkan] Implement task function parsing This just sets up the memory block and cexpr descriptors for the parameters, parameter parsing is separate (and next). The parameters are aligned to their size.
2023-02-12 16:43:17 +00:00
void *param_data;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
} qfv_taskinfo_t;
typedef struct qfv_attachmentrefinfo_s {
[vulkan] Get render info parsing partially working A bunch of missed struct members, incorrect parse types, and some logic errors in the parse setup. Still not working due to problems with vectors from plist string references and some other errors, but getting there.
2023-02-10 10:45:02 +00:00
const char *name;
[vulkan] Try to create render passes and pipelines The render passes seem to be created successfully, but pipelines fail due to not having layout set, resulting in a segfault (bug in validation layers?).
2023-02-20 15:44:26 +00:00
int line;
[vulkan] Get render info parsing partially working A bunch of missed struct members, incorrect parse types, and some logic errors in the parse setup. Still not working due to problems with vectors from plist string references and some other errors, but getting there.
2023-02-10 10:45:02 +00:00
VkImageLayout layout;
[vkgen] Improve .type parse spec handling .dictionary can ask for standard parsing via a .parse key (value is ignored currently). Fields can use $auto to use standard parsing for that field. If either is used, the plist field descriptors are written.
2023-02-18 08:00:52 +00:00
VkPipelineColorBlendAttachmentState blend;
[vulkan] Get render info parsing partially working A bunch of missed struct members, incorrect parse types, and some logic errors in the parse setup. Still not working due to problems with vectors from plist string references and some other errors, but getting there.
2023-02-10 10:45:02 +00:00
} qfv_attachmentrefinfo_t;
typedef struct qfv_attachmentsetinfo_s {
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
uint32_t num_input;
[vulkan] Get render info parsing partially working A bunch of missed struct members, incorrect parse types, and some logic errors in the parse setup. Still not working due to problems with vectors from plist string references and some other errors, but getting there.
2023-02-10 10:45:02 +00:00
qfv_attachmentrefinfo_t *input;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
uint32_t num_color;
[vulkan] Get render info parsing partially working A bunch of missed struct members, incorrect parse types, and some logic errors in the parse setup. Still not working due to problems with vectors from plist string references and some other errors, but getting there.
2023-02-10 10:45:02 +00:00
qfv_attachmentrefinfo_t *color;
qfv_attachmentrefinfo_t *resolve;
qfv_attachmentrefinfo_t *depth;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
uint32_t num_preserve;
[vulkan] Try to create render passes and pipelines The render passes seem to be created successfully, but pipelines fail due to not having layout set, resulting in a segfault (bug in validation layers?).
2023-02-20 15:44:26 +00:00
qfv_reference_t *preserve;
[vulkan] Get render info parsing partially working A bunch of missed struct members, incorrect parse types, and some logic errors in the parse setup. Still not working due to problems with vectors from plist string references and some other errors, but getting there.
2023-02-10 10:45:02 +00:00
} qfv_attachmentsetinfo_t;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
typedef struct qfv_pipelineinfo_s {
vec4f_t color;
const char *name;
uint32_t num_tasks;
qfv_taskinfo_t *tasks;
[vkgen] Improve .type parse spec handling .dictionary can ask for standard parsing via a .parse key (value is ignored currently). Fields can use $auto to use standard parsing for that field. If either is used, the plist field descriptors are written.
2023-02-18 08:00:52 +00:00
VkPipelineCreateFlags flags;
uint32_t num_graph_stages;
const VkPipelineShaderStageCreateInfo *graph_stages;
const VkPipelineVertexInputStateCreateInfo *vertexInput;
const VkPipelineInputAssemblyStateCreateInfo *inputAssembly;
const VkPipelineTessellationStateCreateInfo *tessellation;
const VkPipelineViewportStateCreateInfo *viewport;
const VkPipelineRasterizationStateCreateInfo *rasterization;
const VkPipelineMultisampleStateCreateInfo *multisample;
const VkPipelineDepthStencilStateCreateInfo *depthStencil;
const VkPipelineColorBlendStateCreateInfo *colorBlend;
const VkPipelineDynamicStateCreateInfo *dynamic;
[vulkan] Create the render images and views And tear them down again on shutdown. The images and views are in a qfv_resource_t block, making their management much easier.
2023-02-19 03:53:02 +00:00
qfv_reference_t layout;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
} qfv_pipelineinfo_t;
typedef struct qfv_subpassinfo_s {
vec4f_t color;
const char *name;
uint32_t num_dependencies;
qfv_dependencyinfo_t *dependencies;
[vulkan] Use correct type for subpass attachments Subpass attachments needs to be an attachment set, not just an array of refs. The parsing was correct.
2023-02-18 08:16:50 +00:00
qfv_attachmentsetinfo_t *attachments;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
uint32_t num_pipelines;
qfv_pipelineinfo_t *pipelines;
[vkgen] Improve .type parse spec handling .dictionary can ask for standard parsing via a .parse key (value is ignored currently). Fields can use $auto to use standard parsing for that field. If either is used, the plist field descriptors are written.
2023-02-18 08:00:52 +00:00
qfv_pipelineinfo_t *base_pipeline;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
} qfv_subpassinfo_t;
[vulkan] Use references for views and pipelines I'm pretty sure I don't want to require views to be created and pipelines to be parsed just to parse the render pass info.
2023-02-11 17:40:52 +00:00
typedef struct qfv_framebufferinfo_s {
qfv_reference_t *attachments;
uint32_t num_attachments;
uint32_t width;
uint32_t height;
uint32_t layers;
} qfv_framebufferinfo_t;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
typedef struct qfv_renderpassinfo_s {
[vulkan] Try to create render passes and pipelines The render passes seem to be created successfully, but pipelines fail due to not having layout set, resulting in a segfault (bug in validation layers?).
2023-02-20 15:44:26 +00:00
vec4f_t color;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
const char *name;
uint32_t num_attachments;
qfv_attachmentinfo_t *attachments;
[vulkan] Use references for views and pipelines I'm pretty sure I don't want to require views to be created and pipelines to be parsed just to parse the render pass info.
2023-02-11 17:40:52 +00:00
qfv_framebufferinfo_t framebuffer;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
uint32_t num_subpasses;
qfv_subpassinfo_t *subpasses;
} qfv_renderpassinfo_t;
typedef struct qfv_renderinfo_s {
[vulkan] Add initial render info parser It doesn't work yet, but I've some otherwise breaking changes I want in (getting this in now prevents the breakage).
2023-02-09 12:17:04 +00:00
struct memsuper_s *memsuper;
[vulkan] Create render passes and pipelines There are many issues (in particular, shutdown doesn't clean up properly), but creation passes validation.
2023-02-26 18:00:14 +00:00
struct plitem_s *plitem;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
uint32_t num_images;
qfv_imageinfo_t *images;
uint32_t num_views;
qfv_imageviewinfo_t *views;
uint32_t num_renderpasses;
qfv_renderpassinfo_t *renderpasses;
[vulkan] Create the render images and views And tear them down again on shutdown. The images and views are in a qfv_resource_t block, making their management much easier.
2023-02-19 03:53:02 +00:00
qfv_output_t output;
[vulkan] Parse in descriptor set layouts For now, just their create info is parsed, but they will be created on demand. Most importantly, they are named for ease of use in pipeline layouts.
2023-02-26 11:54:11 +00:00
uint32_t num_descriptorsets;
qfv_descriptorsetinfo_t *descriptorsets;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
} qfv_renderinfo_t;
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
typedef struct qfv_label_s {
vec4f_t color;
const char *name;
} qfv_label_t;
typedef struct qfv_bar_s {
VkBuffer *buffers;
VkDeviceSize *offsets;
uint32_t firstBinding;
uint32_t bindingCount;
} qfv_bar_t;
typedef struct qfv_pipeline_s {
qfv_label_t label;
VkPipelineBindPoint bindPoint;
VkPipeline pipeline;
VkPipelineLayout layout;
VkViewport viewport;
VkRect2D scissor;
struct qfv_push_constants_s *push_constants;
uint32_t num_push_constants;
uint32_t num_descriptor_sets;
uint32_t first_descriptor_set;
VkDescriptorSet *descriptor_sets;
[vulkan] Try to create render passes and pipelines The render passes seem to be created successfully, but pipelines fail due to not having layout set, resulting in a segfault (bug in validation layers?).
2023-02-20 15:44:26 +00:00
uint32_t task_count;
qfv_taskinfo_t *tasks;
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
} qfv_pipeline_t;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
typedef struct qfv_subpass_s_ {
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
qfv_label_t label;
VkCommandBufferBeginInfo beginInfo;
VkCommandBuffer cmd;
[vulkan] Try to create render passes and pipelines The render passes seem to be created successfully, but pipelines fail due to not having layout set, resulting in a segfault (bug in validation layers?).
2023-02-20 15:44:26 +00:00
uint32_t pipeline_count;
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
qfv_pipeline_t *pipelines;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
} qfv_subpass_t_;
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
typedef struct qfv_renderpass_s_ {
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
struct vulkan_ctx_s *vulkan_ctx;
qfv_label_t label; // for debugging
VkCommandBuffer cmd;
VkRenderPassBeginInfo beginInfo;
VkSubpassContents subpassContents;
//struct qfv_imageset_s *attachment_images;
//struct qfv_imageviewset_s *attachment_views;
//VkDeviceMemory attachmentMemory;
//size_t attachmentMemory_size;
//qfv_output_t output;
uint32_t subpass_count;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
qfv_subpass_t_ *subpasses;
} qfv_renderpass_t_;
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
[vulkan] Create the render images and views And tear them down again on shutdown. The images and views are in a qfv_resource_t block, making their management much easier.
2023-02-19 03:53:02 +00:00
typedef struct qfv_render_s {
struct qfv_resource_s *resources;
struct qfv_resobj_s *images;
struct qfv_resobj_s *image_views;
[vulkan] Try to create render passes and pipelines The render passes seem to be created successfully, but pipelines fail due to not having layout set, resulting in a segfault (bug in validation layers?).
2023-02-20 15:44:26 +00:00
VkRenderPass *renderpass_res;
VkPipeline *pipelines;
uint32_t num_renderpasses;
qfv_renderpass_t_ *renderpasses;
[vulkan] Create the render images and views And tear them down again on shutdown. The images and views are in a qfv_resource_t block, making their management much easier.
2023-02-19 03:53:02 +00:00
} qfv_render_t;
typedef struct qfv_renderctx_s {
struct hashctx_s *hashctx;
exprtab_t task_functions;
qfv_renderinfo_t *renderinfo;
qfv_render_t *render;
} qfv_renderctx_t;
[vulkan] Generate parse data for new render pass structs There's still a lot of work to do, but the basics are in. The spec will be parsed into info structs that can then be further processed to generate all the actual structs, generally making things a little less timing dependent (eg, image view info refers to its image by name). The new render pass and subpass structs have their names mangled for now until I can switch over to the new system.
2023-02-09 05:52:43 +00:00
void QFV_RunRenderPass (qfv_renderpass_t_ *rp, struct vulkan_ctx_s *ctx);
[vulkan] Create the render images and views And tear them down again on shutdown. The images and views are in a qfv_resource_t block, making their management much easier.
2023-02-19 03:53:02 +00:00
void QFV_LoadRenderInfo (struct vulkan_ctx_s *ctx);
void QFV_BuildRender (struct vulkan_ctx_s *ctx);
[vulkan] Create a render context This gets an empty (no tasks or pipelines connected) render context initialized and available for other subsystems to register their task functions. Nothing is using it yet, but the test parse of rp_main_def fails gracefully (needs those tasks).
2023-02-13 08:45:36 +00:00
void QFV_Render_Init (struct vulkan_ctx_s *ctx);
[vulkan] Create the render images and views And tear them down again on shutdown. The images and views are in a qfv_resource_t block, making their management much easier.
2023-02-19 03:53:02 +00:00
void QFV_Render_Shutdown (struct vulkan_ctx_s *ctx);
[vulkan] Register task functions for the pipelines They're currently just stubs, but this gets the render info loading working without any errors. The next step is to connect up pipelines and create the image resources, then implementing the task functions will have meaning.
2023-02-13 15:55:22 +00:00
void QFV_Render_AddTasks (struct vulkan_ctx_s *ctx, exprsym_t *task_sys);
[vulkan] Begin work on a new render pass system While the old system did get things going, it felt clunky to set up, especially when it came to variations on render passes (eg, flat vs cube-mapped). Also, much of it felt inside-out, especially the separation of pipelines and render passes: having to specify the render pass and subpass in the pipeline spec made the spec feel overly coupled to the render pass setup. While this is the case in Vulkan, it is not reflected properly in the pipeline spec. The new system will adjust the render pass and subpass parameters of the pipeline spec as needed, making the pipeline specs more reusable, and hopefully less error prone as the pipelines are directly referenced by the subpasses that use them. In addition, subpass dependencies should be much easier to set up as only the dependent subpass specifies the dependency and the subpass source dependency is mentioned by name. Frame buffer attachments also get a similar treatment. The new spec "format" isn't quite finalized (needs to meet the enemy known as parsing) but it feels like a good starting place.
2023-01-30 04:00:35 +00:00
#endif//__QF_Vulkan_render_h
Reference in a new issue Copy permalink