qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-11-23 21:02:50 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/include/QF/Vulkan/qf_vid.h

106 lines
3 KiB
C
Raw Normal View History

Start work on a Vulkan-based renderer Doesn't do much other than create an instance and enumerate some stuff, but the build system is working.
2019-07-06 05:42:53 +00:00
/*
Vulkan/qf_vid.h
vulkan vid stuff from the renderer.
[vulkan] Correct a pile of copyright attributions Id Software had pretty much nothing to do with the vulkan renderer (they still get credit for code that's heavily based on the original quake code, of course).
2022-05-04 05:39:47 +00:00
Copyright (C) 2019 Bill Currie <bill@taniwha.org>
Start work on a Vulkan-based renderer Doesn't do much other than create an instance and enumerate some stuff, but the build system is working.
2019-07-06 05:42:53 +00:00
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
*/
#ifndef __QF_Vulkan_vid_h
#define __QF_Vulkan_vid_h
#include "QF/Vulkan/cvars.h"
Completely rework the vulkan related api Things don't work yet, but this feels much cleaner.
2019-07-12 04:15:25 +00:00
#ifndef VK_NO_PROTOTYPES
#define VK_NO_PROTOTYPES
#endif
#include <vulkan/vulkan.h>
[vulkan] Partially document bsp rendering This did involve changing some field names and a little bit of cleanup, but I've got a better handle on what's going on (I think I was in one of those coding trances where I quickly forget how things work).
2022-06-08 09:16:10 +00:00
/** \defgroup vulkan Vulkan Renderer
*/
[vulkan] Move main render pass setup to Vulkan_Main And support sorting of render passes by an order index.
2022-05-31 01:41:19 +00:00
enum {
[vulkan] Get particle compute pipelines running I don't yet know whether they actually work (not rendering yet), but the system isn't locking up, and shutdown is clean, so at least resources are handled correctly.
2022-11-27 15:52:07 +00:00
QFV_rp_particles,
[vulkan] Hook up the shadow map render pass There are some issues with the light renderers getting mangled, and only the first light is even touched (just begin and end of render pass), but this gets a lot of the framework into place.
2022-05-31 03:43:04 +00:00
QFV_rp_shadowmap,
[vulkan] Add a module to handle output When working, this will handle the output to the swap-chain images and any final post-processing effects (gamma correction, screen scaling, etc). However, currently the screen is just black because the image for getting the main render pass output isn't hooked up yet.
2022-11-22 08:47:36 +00:00
QFV_rp_preoutput,
[vulkan] Implement order implement transparency It's a bit flaky for particles, especially at higher frame rates, but that's due to supporting only 64 overlapping pixels. A reasonable solution is probably switching to a priority heap for the "sort" and upping the limit.
2022-11-30 18:00:47 +00:00
QFV_rp_translucent,
[vulkan] Move main render pass setup to Vulkan_Main And support sorting of render passes by an order index.
2022-05-31 01:41:19 +00:00
QFV_rp_main,
[vulkan] Get multiple frame buffers working Now each (high level) render pass can have its own frame buffer. The current goal is to get the final output render pass to just transfer the composed output to the swap chain image, potentially with scaling (my laptop might be able to cope).
2022-11-21 08:25:55 +00:00
QFV_rp_output,
[vulkan] Move main render pass setup to Vulkan_Main And support sorting of render passes by an order index.
2022-05-31 01:41:19 +00:00
};
[vulkan] Start moving towards a deferred renderer After getting lights even vaguely working for alias models, I realized that it just wasn't going to be feasible to do nice lighting with forward rendering. This gets the bulk of the work done for deferred rendering, but still need to sort out the shaders before any real testing can be done.
2021-02-14 02:35:06 +00:00
//FIXME location
[vulkan] Use correct vertex shader for skys This gets skys rendering again, but their depth is incorrect.
2021-03-22 23:25:56 +00:00
typedef enum {
[vulkan] Implement order implement transparency It's a bit flaky for particles, especially at higher frame rates, but that's due to supporting only 64 overlapping pixels. A reasonable solution is probably switching to a priority heap for the "sort" and upping the limit.
2022-11-30 18:00:47 +00:00
QFV_passDepth, // geometry
QFV_passTranslucentFrag, // geometry
QFV_passGBuffer, // geometry
QFV_passLighting, // single triangle
QFV_passCompose, // single triangle
[vulkan] Start moving towards a deferred renderer After getting lights even vaguely working for alias models, I realized that it just wasn't going to be feasible to do nice lighting with forward rendering. This gets the bulk of the work done for deferred rendering, but still need to sort out the shaders before any real testing can be done.
2021-02-14 02:35:06 +00:00
QFV_NumPasses
[vulkan] Use correct vertex shader for skys This gets skys rendering again, but their depth is incorrect.
2021-03-22 23:25:56 +00:00
} QFV_Subpass;
[vulkan] Start moving towards a deferred renderer After getting lights even vaguely working for alias models, I realized that it just wasn't going to be feasible to do nice lighting with forward rendering. This gets the bulk of the work done for deferred rendering, but still need to sort out the shaders before any real testing can be done.
2021-02-14 02:35:06 +00:00
[vulkan] Add a position buffer to the g-buffer While I could reconstruct the position from the screen coords and depth, this is easier and good enough for now. Reconstruction is an optimization thing.
2021-02-25 04:46:33 +00:00
enum {
QFV_attachDepth,
QFV_attachColor,
[vulkan] Implement deferred emission (fullbrights) That was... easier than expected. A little more tedious that I would have liked, but my scripting system isn't perfect (I suspect it's best suited as the output of a code generator), and the C side could do with a little more automation.
2021-03-22 10:08:16 +00:00
QFV_attachEmission,
[vulkan] Add a position buffer to the g-buffer While I could reconstruct the position from the screen coords and depth, this is easier and good enough for now. Reconstruction is an optimization thing.
2021-02-25 04:46:33 +00:00
QFV_attachNormal,
QFV_attachPosition,
QFV_attachOpaque,
QFV_attachSwapchain,
};
Remove global vulkan_ctx While I can't say that I'm happy with the details of vulkan_ctx_t, I am pretty sure I don't want to be limited to having only one.
2019-07-09 02:54:23 +00:00
struct vulkan_ctx_s;
[vulkan] Start moving towards a deferred renderer After getting lights even vaguely working for alias models, I realized that it just wasn't going to be feasible to do nice lighting with forward rendering. This gets the bulk of the work done for deferred rendering, but still need to sort out the shaders before any real testing can be done.
2021-02-14 02:35:06 +00:00
void Vulkan_DestroyFrames (struct vulkan_ctx_s *ctx);
void Vulkan_CreateFrames (struct vulkan_ctx_s *ctx);
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
void Vulkan_CreateCapture (struct vulkan_ctx_s *ctx);
[vulkan] Make Vulkan_CreateRenderPass more generally useful It now lives in vulkan_renderpass.c and takes most of its parameters from plist configs (just the name (which is used to find the config), output spec, and draw function from C). Even the debug colors and names are taken from the config.
2022-05-30 06:58:22 +00:00
void Vulkan_CreateRenderPasses (struct vulkan_ctx_s *ctx);
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
void Vulkan_DestroyRenderPasses (struct vulkan_ctx_s *ctx);
Implement swapchain creation
2019-07-10 15:58:14 +00:00
void Vulkan_CreateSwapchain (struct vulkan_ctx_s *ctx);
Create a window and a surface for vulkan Yay, segfaults in R_Init :)
2019-07-09 07:33:44 +00:00
void Vulkan_CreateDevice (struct vulkan_ctx_s *ctx);
Remove global vulkan_ctx While I can't say that I'm happy with the details of vulkan_ctx_t, I am pretty sure I don't want to be limited to having only one.
2019-07-09 02:54:23 +00:00
void Vulkan_Init_Common (struct vulkan_ctx_s *ctx);
void Vulkan_Shutdown_Common (struct vulkan_ctx_s *ctx);
[vulkan] Create a staging buffer struct And move the barrier prefabs into a more convenient place.
2021-01-10 16:24:15 +00:00
void Vulkan_CreateStagingBuffers (struct vulkan_ctx_s *ctx);
Start work on a Vulkan-based renderer Doesn't do much other than create an instance and enumerate some stuff, but the build system is working.
2019-07-06 05:42:53 +00:00
[vulkan] Add support for compute shaders This needed changing Vulkan_CreatePipeline to Vulkan_CreateGraphicsPipeline for consistency (and parsing the difference from a plist seemed... not worth thinking about).
2021-12-16 14:00:17 +00:00
VkPipeline Vulkan_CreateComputePipeline (struct vulkan_ctx_s *ctx,
const char *name);
VkPipeline Vulkan_CreateGraphicsPipeline (struct vulkan_ctx_s *ctx,
const char *name);
[vulkan] Rework pipeline parsing for better reuse It's not entirely there yet, but the basics are working. Work is still needed for avoiding duplication of objects (different threads will have different contexts and thus different tables, so necessary per-thread duplication should not become a problem) and general access to arbitrary fields (mostly just parsing the strings)
2021-02-04 08:03:49 +00:00
VkDescriptorPool Vulkan_CreateDescriptorPool (struct vulkan_ctx_s *ctx,
const char *name);
VkPipelineLayout Vulkan_CreatePipelineLayout (struct vulkan_ctx_s *ctx,
const char *name);
VkSampler Vulkan_CreateSampler (struct vulkan_ctx_s *ctx, const char *name);
VkDescriptorSetLayout Vulkan_CreateDescriptorSetLayout(struct vulkan_ctx_s*ctx,
const char *name);
[vulkan] Add entity labels to command queues Brush models looked a little too tricky due to the very different style of command queue, so that's left for now, but alias, iqm and sprite entities are now labeled. The labels are made up of the lower 5 hex digits of the entity address, the position, and colored by the normalized position vector. Not sure that's the best choice as it does mean the color changes as the entity moves, and can be quite subtle between nearby entities, but it still helps identify the entities in the command buffer. And, as I suspected, I've got multiple draw calls for the one ogre. Now to find out why.
2022-05-07 05:12:02 +00:00
struct entity_s;
void Vulkan_BeginEntityLabel (struct vulkan_ctx_s *ctx, VkCommandBuffer cmd,
[scene] Make entity_t just an entity id for ECS This puts the hierarchy (transform) reference, animation, visibility, renderer, active, and old_origin data in separate components. There are a few bugs (crashes on grenade explosions in gl/glsl/vulkan, immediately in sw, reasons known, missing brush models in vulkan). While quake doesn't really need an ECS, the direction I want to take QF does, and it does seem to have improved memory bandwidth a little (uncertain). However, there's a lot more work to go (especially fixing the above bugs), but this seems to be a good start.
2022-10-23 01:32:09 +00:00
struct entity_s ent);
[vulkan] Add entity labels to command queues Brush models looked a little too tricky due to the very different style of command queue, so that's left for now, but alias, iqm and sprite entities are now labeled. The labels are made up of the lower 5 hex digits of the entity address, the position, and colored by the normalized position vector. Not sure that's the best choice as it does mean the color changes as the entity moves, and can be quite subtle between nearby entities, but it still helps identify the entities in the command buffer. And, as I suspected, I've got multiple draw calls for the one ogre. Now to find out why.
2022-05-07 05:12:02 +00:00
[vulkan] Make Vulkan_CreateRenderPass more generally useful It now lives in vulkan_renderpass.c and takes most of its parameters from plist configs (just the name (which is used to find the config), output spec, and draw function from C). Even the debug colors and names are taken from the config.
2022-05-30 06:58:22 +00:00
struct plitem_s *Vulkan_GetConfig (struct vulkan_ctx_s *ctx, const char *name);
[vulkan] Add cvars to control vulkan 3d frame buffer size Thanks to the 3d frame buffer output being separate from the swap chain, it's possible to have a different frame buffer size from the window size, allowing for a smaller buffer and thus my laptop can cope (mostly) with the vulkan renderer.
2022-12-02 04:17:07 +00:00
extern int vulkan_frame_width;
extern int vulkan_frame_height;
[vulkan] Add a cvar for oit fragment buffer size My laptop can't have a buffer larger than 128MB, but 16M fragments wants 512MB. Also, someone running at 4k will probably want a larger buffer.
2022-12-02 04:29:15 +00:00
extern int vulkan_oit_fragments;
[vulkan] Add cvars to control vulkan 3d frame buffer size Thanks to the 3d frame buffer output being separate from the swap chain, it's possible to have a different frame buffer size from the window size, allowing for a smaller buffer and thus my laptop can cope (mostly) with the vulkan renderer.
2022-12-02 04:17:07 +00:00
Start work on a Vulkan-based renderer Doesn't do much other than create an instance and enumerate some stuff, but the build system is working.
2019-07-06 05:42:53 +00:00
#endif // __QF_Vulkan_vid_h
Reference in a new issue Copy permalink