qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-12-02 17:12:55 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/libs/video/renderer/vulkan/render.c

469 lines
13 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
/*
render.c
Vulkan render manager
Copyright (C) 2023 Bill Currie <bill@taniwha.org>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
*/
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
#ifdef HAVE_MATH_H
# include <math.h>
#endif
#ifdef HAVE_STRING_H
# include <string.h>
#endif
#ifdef HAVE_STRINGS_H
# include <strings.h>
#endif
[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
#include "QF/cmem.h"
[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
#include "QF/hash.h"
[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
#include "QF/va.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/Vulkan/command.h"
#include "QF/Vulkan/debug.h"
#include "QF/Vulkan/device.h"
#include "QF/Vulkan/render.h"
[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
#include "QF/Vulkan/resource.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/Vulkan/pipeline.h"
#include "vid_vulkan.h"
[vulkan] Attempt to load the render info spec It fails due to not supporting labeled arrays yet. I'm currently thinking about the design for vkgen.
2023-02-10 02:04:11 +00:00
#include "vkparse.h"
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
VkCommandBuffer
QFV_GetCmdBufffer (vulkan_ctx_t *ctx, bool secondary)
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
__auto_type rctx = ctx->render_context;
__auto_type job = rctx->job;
VkCommandBufferAllocateInfo cinfo = {
.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_ALLOCATE_INFO,
.commandPool = job->command_pool,
.level = secondary ? VK_COMMAND_BUFFER_LEVEL_SECONDARY
: VK_COMMAND_BUFFER_LEVEL_PRIMARY,
.commandBufferCount = 1,
};
VkCommandBuffer cmd;
dfunc->vkAllocateCommandBuffers (device->dev, &cinfo, &cmd);
return cmd;
}
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
void
QFV_AppendCmdBuffer (vulkan_ctx_t *ctx, VkCommandBuffer cmd)
{
__auto_type rctx = ctx->render_context;
__auto_type job = rctx->job;
DARRAY_APPEND (&job->commands, cmd);
}
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
static void
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
run_tasks (uint32_t task_count, qfv_taskinfo_t *tasks, qfv_taskctx_t *ctx)
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
{
for (uint32_t i = 0; i < task_count; i++) {
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
tasks[i].func->func (tasks[i].params, 0, (exprctx_t *) ctx);
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
}
}
[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
static void
run_pipeline (qfv_pipeline_t *pipeline, VkCommandBuffer cmd, vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
dfunc->vkCmdBindPipeline (cmd, pipeline->bindPoint, pipeline->pipeline);
dfunc->vkCmdSetViewport (cmd, 0, 1, &pipeline->viewport);
dfunc->vkCmdSetScissor (cmd, 0, 1, &pipeline->scissor);
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
qfv_taskctx_t taskctx = {
.ctx = ctx,
.pipeline = pipeline,
[vulkan] Pass the current command buffer to tasks Compute and render tasks need to be able to submit commands.
2023-06-16 13:34:08 +00:00
.cmd = cmd,
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
};
run_tasks (pipeline->task_count, pipeline->tasks, &taskctx);
if (pipeline->num_descriptorsets) {
[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
dfunc->vkCmdBindDescriptorSets (cmd, pipeline->bindPoint,
pipeline->layout,
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
pipeline->first_descriptorset,
pipeline->num_descriptorsets,
pipeline->descriptorsets,
[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
0, 0);
}
}
// https://themaister.net/blog/2019/08/14/yet-another-blog-explaining-vulkan-synchronization/
static void
[vulkan] Switch around renderpass and subpass names The old structs will go away eventually, and I'm tired of seeing that _ tail.
2023-06-15 04:13:52 +00:00
run_subpass (qfv_subpass_t *sp, VkCommandBuffer cmd, vulkan_ctx_t *ctx)
[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_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
dfunc->vkResetCommandBuffer (cmd, 0);
dfunc->vkBeginCommandBuffer (cmd, &sp->beginInfo);
QFV_duCmdBeginLabel (device, cmd, sp->label.name,
{VEC4_EXP (sp->label.color)});
[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
for (uint32_t i = 0; i < sp->pipeline_count; i++) {
[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
__auto_type pipeline = &sp->pipelines[i];
run_pipeline (pipeline, cmd, ctx);
}
QFV_duCmdEndLabel (device, cmd);
dfunc->vkEndCommandBuffer (cmd);
}
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
static void
[vulkan] Switch around renderpass and subpass names The old structs will go away eventually, and I'm tired of seeing that _ tail.
2023-06-15 04:13:52 +00:00
run_renderpass (qfv_renderpass_t *rp, vulkan_ctx_t *ctx)
[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] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
printf ("run_renderpass: %s\n", rp->label.name);
[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_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
__auto_type rctx = ctx->render_context;
__auto_type job = rctx->job;
[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] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
VkCommandBuffer cmd = QFV_GetCmdBufffer (ctx, false);
[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
VkCommandBufferBeginInfo beginInfo = {
VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
};
dfunc->vkBeginCommandBuffer (cmd, &beginInfo);
QFV_duCmdBeginLabel (device, cmd, rp->label.name,
{VEC4_EXP (rp->label.color)});
dfunc->vkCmdBeginRenderPass (cmd, &rp->beginInfo, rp->subpassContents);
for (uint32_t i = 0; i < rp->subpass_count; i++) {
__auto_type sp = &rp->subpasses[i];
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
VkCommandBuffer subcmd = QFV_GetCmdBufffer (ctx, true);
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
run_subpass (sp, subcmd, ctx);
dfunc->vkCmdExecuteCommands (cmd, 1, &subcmd);
[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
//FIXME comment is a bit off as exactly one buffer is always submitted
//
//Regardless of whether any commands were submitted for this
//subpass, must step through each and every subpass, otherwise
//the attachments won't be transitioned correctly.
//However, only if not the last (or only) subpass.
if (i < rp->subpass_count - 1) {
dfunc->vkCmdNextSubpass (cmd, rp->subpassContents);
}
}
QFV_CmdEndLabel (device, cmd);
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
DARRAY_APPEND (&job->commands, cmd);
[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] Attempt to load the render info spec It fails due to not supporting labeled arrays yet. I'm currently thinking about the design for vkgen.
2023-02-10 02:04:11 +00:00
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
static void
run_compute_pipeline (qfv_pipeline_t *pipeline, VkCommandBuffer cmd,
vulkan_ctx_t *ctx)
{
printf ("run_compute_pipeline: %s\n", pipeline->label.name);
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
dfunc->vkCmdBindPipeline (cmd, pipeline->bindPoint, pipeline->pipeline);
qfv_taskctx_t taskctx = {
.ctx = ctx,
.pipeline = pipeline,
[vulkan] Pass the current command buffer to tasks Compute and render tasks need to be able to submit commands.
2023-06-16 13:34:08 +00:00
.cmd = cmd,
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
};
run_tasks (pipeline->task_count, pipeline->tasks, &taskctx);
if (pipeline->num_descriptorsets) {
dfunc->vkCmdBindDescriptorSets (cmd, pipeline->bindPoint,
pipeline->layout,
pipeline->first_descriptorset,
pipeline->num_descriptorsets,
pipeline->descriptorsets,
0, 0);
}
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
vec4u_t d = pipeline->dispatch;
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
dfunc->vkCmdDispatch (cmd, d[0], d[1], d[2]);
}
static void
run_compute (qfv_compute_t *comp, vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
__auto_type rctx = ctx->render_context;
__auto_type job = rctx->job;
[vulkan] Get some subsystems passing validation This is with the new render job scheme. I very much doubt it actually works (can't start testing until everything passes, and it's disabled for the moment (define in vid_render_vulkan.c)), but it's helping iron out what more is needed in the render system.
2023-06-15 06:17:39 +00:00
VkCommandBuffer cmd = QFV_GetCmdBufffer (ctx, false);
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
VkCommandBufferBeginInfo beginInfo = {
.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
.flags = VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT,
};
dfunc->vkBeginCommandBuffer (cmd, &beginInfo);
for (uint32_t i = 0; i < comp->pipeline_count; i++) {
__auto_type pipeline = &comp->pipelines[i];
run_compute_pipeline (pipeline, cmd, ctx);
}
dfunc->vkEndCommandBuffer (cmd);
DARRAY_APPEND (&job->commands, cmd);
}
static void
run_process (qfv_process_t *proc, vulkan_ctx_t *ctx)
{
qfv_taskctx_t taskctx = {
.ctx = ctx,
};
run_tasks (proc->task_count, proc->tasks, &taskctx);
}
void
QFV_RunRenderJob (vulkan_ctx_t *ctx)
{
__auto_type rctx = ctx->render_context;
__auto_type job = rctx->job;
for (uint32_t i = 0; i < job->num_steps; i++) {
__auto_type step = &job->steps[i];
printf ("run_step: %s\n", step->label.name);
if (step->render) {
run_renderpass (step->render->active, ctx);
}
if (step->compute) {
run_compute (step->compute, ctx);
}
if (step->process) {
run_process (step->process, ctx);
}
}
}
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
#if 0
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
void
QFV_DestroyFramebuffer (vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
__auto_type rctx = ctx->render_context;
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
__auto_type job = rctx->job;
__auto_type rp = &job->renderpasses[0];
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
if (rp->beginInfo.framebuffer) {
VkFramebuffer framebuffer = rp->beginInfo.framebuffer;
rp->beginInfo.framebuffer = 0;
dfunc->vkDestroyFramebuffer (device->dev, framebuffer, 0);
}
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
}
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
#endif
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
static VkImageView __attribute__((pure))
find_imageview (qfv_reference_t *ref, qfv_renderctx_t *rctx)
{
__auto_type jinfo = rctx->jobinfo;
__auto_type job = rctx->job;
const char *name = ref->name;
if (strncmp (name, "$imageviews.", 7) == 0) {
name += 7;
}
for (uint32_t i = 0; i < jinfo->num_imageviews; i++) {
__auto_type vi = &jinfo->imageviews[i];
__auto_type vo = &job->image_views[i];
if (strcmp (name, vi->name) == 0) {
return vo->image_view.view;
}
}
Sys_Error ("%d:invalid imageview: %s", ref->line, ref->name);
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
}
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
static void
QFV_CreateFramebuffer (vulkan_ctx_t *ctx, qfv_renderpass_t *rp)
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
{
__auto_type rctx = ctx->render_context;
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
auto fb = rp->framebufferinfo;
VkImageView attachments[fb->num_attachments];
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
VkFramebufferCreateInfo cInfo = {
.sType = VK_STRUCTURE_TYPE_FRAMEBUFFER_CREATE_INFO,
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
.attachmentCount = fb->num_attachments,
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
.pAttachments = attachments,
.renderPass = rp->beginInfo.renderPass,
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
.width = fb->width,
.height = fb->height,
.layers = fb->layers,
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
};
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
for (uint32_t i = 0; i < fb->num_attachments; i++) {
attachments[i] = find_imageview (&fb->attachments[i].view, rctx);
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
}
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
VkFramebuffer framebuffer;
dfunc->vkCreateFramebuffer (device->dev, &cInfo, 0, &framebuffer);
QFV_duSetObjectName (device, VK_OBJECT_TYPE_FRAMEBUFFER, framebuffer,
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
va (ctx->va_ctx, "framebuffer:%s", rp->label.name));
[vulkan] Create a framebuffer for the first render pass Currently just the one framebuffer is created, but I want to get things running soon.
2023-03-02 09:33:16 +00:00
rp->beginInfo.framebuffer = framebuffer;
for (uint32_t i = 0; i < rp->subpass_count; i++) {
__auto_type sp = &rp->subpasses[i];
sp->inherit.framebuffer = framebuffer;
}
}
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
static void
wait_on_fence (const exprval_t **params, exprval_t *result, exprctx_t *ectx)
{
__auto_type taskctx = (qfv_taskctx_t *) ectx;
vulkan_ctx_t *ctx = taskctx->ctx;
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
VkDevice dev = device->dev;
__auto_type frame = &ctx->frames.a[ctx->curFrame];
dfunc->vkWaitForFences (dev, 1, &frame->fence, VK_TRUE, 2000000000);
}
static void
update_framebuffer (const exprval_t **params, exprval_t *result,
exprctx_t *ectx)
{
auto taskctx = (qfv_taskctx_t *) ectx;
auto ctx = taskctx->ctx;
auto stepref = params[0];
// cache the render step referenced, using the parameter type as a flag
// for whether the caching has been performed.
if (stepref->type == &cexpr_string) {
if (cexpr_string.size != cexpr_voidptr.size) {
Sys_Error ("string and voidptr incompatible sizes");
}
auto name = *(const char **)stepref->value;
((exprval_t *) stepref)->type = &cexpr_voidptr;
*(void **)stepref->value = 0;
auto job = ctx->render_context->job;
for (uint32_t i = 0; i < job->num_steps; i++) {
auto step = &job->steps[i];
if (!strcmp (step->label.name, name)) {
*(void **)stepref->value = step;
break;
}
}
}
auto step = *(qfv_step_t **)stepref->value;
auto render = step->render;
auto rp = render->active;
if (!rp->beginInfo.framebuffer) {
QFV_CreateFramebuffer (ctx, rp);
}
}
static exprfunc_t wait_on_fence_func[] = {
{ .func = wait_on_fence },
{}
};
static exprtype_t *update_framebuffer_params[] = {
&cexpr_string,
};
static exprfunc_t update_framebuffer_func[] = {
{ .func = update_framebuffer, .num_params = 1, update_framebuffer_params },
{}
};
static exprsym_t render_task_syms[] = {
{ "wait_on_fence", &cexpr_function, wait_on_fence_func },
{ "update_framebuffer", &cexpr_function, update_framebuffer_func },
{}
};
[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 (vulkan_ctx_t *ctx)
{
qfv_renderctx_t *rctx = calloc (1, sizeof (*rctx));
ctx->render_context = rctx;
exprctx_t ectx = { .hashctx = &rctx->hashctx };
exprsym_t syms[] = { {} };
rctx->task_functions.symbols = syms;
cexpr_init_symtab (&rctx->task_functions, &ectx);
rctx->task_functions.symbols = 0;
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
QFV_Render_AddTasks (ctx, render_task_syms);
[vulkan] Attempt to load the render info spec It fails due to not supporting labeled arrays yet. I'm currently thinking about the design for vkgen.
2023-02-10 02:04:11 +00:00
}
[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
[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 (vulkan_ctx_t *ctx)
{
[vulkan] Clean up the render objects on shutdown Not only does this quieten the validation layers, it ensures that all the object handles are named and where they need to be. Also fixes only one pipeline being created instead of the 15 or so.
2023-02-27 05:15:28 +00:00
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
[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
__auto_type rctx = ctx->render_context;
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
if (rctx->job) {
__auto_type job = rctx->job;
[vulkan] Add a step and task to create a framebuffer I don't like the current name (update_framebuffer), but if the referenced render pass doesn't have a framebuffer, one is created. The renderpass is referenced via the active renderpass of the named render step. Unfortunately, this has uncovered a bug in the setup of renderpass objects: main.deferred has output's renderpass, and main.deferred_cube and output have bogus renderpass objects.
2023-06-18 09:42:07 +00:00
//QFV_DestroyFramebuffer (ctx); //FIXME do properly
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
for (uint32_t i = 0; i < job->num_renderpasses; i++) {
dfunc->vkDestroyRenderPass (device->dev, job->renderpasses[i], 0);
[vulkan] Clean up the render objects on shutdown Not only does this quieten the validation layers, it ensures that all the object handles are named and where they need to be. Also fixes only one pipeline being created instead of the 15 or so.
2023-02-27 05:15:28 +00:00
}
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
for (uint32_t i = 0; i < job->num_pipelines; i++) {
dfunc->vkDestroyPipeline (device->dev, job->pipelines[i], 0);
}
for (uint32_t i = 0; i < job->num_layouts; i++) {
dfunc->vkDestroyPipelineLayout (device->dev, job->layouts[i], 0);
[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
}
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
if (job->resources) {
QFV_DestroyResource (ctx->device, job->resources);
free (job->resources);
}
[vulkan] Stub out the basic job execution Really, a bit more than stub as the basic code is there, but nothing works properly yet due to missing resources (especially descriptor sets and pools), and the frame buffer creation is still disabled.
2023-03-28 01:28:44 +00:00
if (job->command_pool) {
dfunc->vkDestroyCommandPool (device->dev, job->command_pool, 0);
}
DARRAY_CLEAR (&job->commands);
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
free (rctx->job);
[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
}
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
if (rctx->jobinfo) {
__auto_type jinfo = rctx->jobinfo;
[vulkan] Be clearer about descriptor set layouts vs sets This get pretty confusing when you refer to both the sets and the set layouts in close vicinity.
2023-03-29 00:45:17 +00:00
for (uint32_t i = 0; i < jinfo->num_descriptorsetlayouts; i++) {
__auto_type setLayout = jinfo->descriptorsetlayouts[i].setLayout;
[vulkan] Clean up the render objects on shutdown Not only does this quieten the validation layers, it ensures that all the object handles are named and where they need to be. Also fixes only one pipeline being created instead of the 15 or so.
2023-02-27 05:15:28 +00:00
dfunc->vkDestroyDescriptorSetLayout (device->dev, setLayout, 0);
}
[vulkan] Implement most of the new job system There's still the actual job objects to create, but all the vulkan bits have been created and get destroyed on shutdown.
2023-03-22 10:32:49 +00:00
delete_memsuper (jinfo->memsuper);
[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
}
if (rctx->task_functions.tab) {
Hash_DelTable (rctx->task_functions.tab);
}
[vulkan] Fix some memory leaks And deal with a shutdown order issue causing cvars to crash on shutdown (due to the hash links being freed too early).
2023-03-05 09:19:54 +00:00
Hash_DelContext (rctx->hashctx);
[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
}
[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 (vulkan_ctx_t *ctx, exprsym_t *task_syms)
{
__auto_type rctx = ctx->render_context;
exprctx_t ectx = { .hashctx = &rctx->hashctx };
for (exprsym_t *sym = task_syms; sym->name; sym++) {
Hash_Add (rctx->task_functions.tab, sym);
for (exprfunc_t *f = sym->value; f->func; f++) {
for (int i = 0; i < f->num_params; i++) {
exprenum_t *e = f->param_types[i]->data;
if (e && !e->symtab->tab) {
cexpr_init_symtab (e->symtab, &ectx);
}
}
}
}
}
Reference in a new issue Copy permalink