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/libs/video/renderer/vid_render_vulkan.c

855 lines
22 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
/*
vid_render_vulkan.c
Vulkan version of the renderer
Copyright (C) 2019 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
Create command pool and frame timing fences Nothing is actually done yet, so the reported fps is around 172k (yes, k), but startup and shutdown seems to be clean (yay validation layers).
2020-02-16 13:45:27 +00:00
#include <stdlib.h>
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
#include <string.h>
Create command pool and frame timing fences Nothing is actually done yet, so the reported fps is around 172k (yes, k), but startup and shutdown seems to be clean (yay validation layers).
2020-02-16 13:45:27 +00:00
[vulkan] Fail gracefully if vulkan driver init fails Well, a little more gracefully than a segfault, at least.
2021-11-29 04:40:56 +00:00
#include "QF/cvar.h"
Rework much of the Vulkan array handling So much for all those little wrappers hiding the device. Some survived, but mostly just the bigger things like device, swapchain, etc.
2020-02-17 11:29:35 +00:00
#include "QF/darray.h"
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
#include "QF/dstring.h"
#include "QF/quakefs.h"
Create a window and a surface for vulkan Yay, segfaults in R_Init :)
2019-07-09 07:33:44 +00:00
#include "QF/sys.h"
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
#include "QF/va.h"
Create a window and a surface for vulkan Yay, segfaults in R_Init :)
2019-07-09 07:33:44 +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
#include "QF/plugin/general.h"
#include "QF/plugin/vid_render.h"
[vulkan] Start work on the alias pipeline
2021-01-25 15:55:45 +00:00
#include "QF/Vulkan/qf_alias.h"
[vulkan] Make a lot of progress for brush models Light maps are maybe updating, but as nothing is actually rendered yet, it's hard to tell.
2021-01-19 16:25:54 +00:00
#include "QF/Vulkan/qf_bsp.h"
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
#include "QF/Vulkan/qf_compose.h"
[vulkan] Make a start on the 2D pipeline Short wrappers for Draw functins are in vid_render_vulkan.c so the vulkan context can be passed on to the actual functions. The 2D shaders are set up similar to those in glsl, but with full 32-bit color (rgba) support instead of paletted. However, the textures are not loaded yet, nor is anything bound.
2021-01-10 06:52:27 +00:00
#include "QF/Vulkan/qf_draw.h"
[vulkan] Add support for IQM models Despite the base IQM specification not supporting blend-shapes, I think IQM will become the basis for QF's generic model representation (at least for the more advanced renderers). After my experience with .mu models (KSP) and unity mesh objects (both normal and skinned), and reviewing the IQM spec, it looks like with the addition of support for blend-shapes, IQM is actually pretty good. This is just the preliminary work to get standard IQM models loading in vulkan (seems to work, along with unloading), and they very basics into the renderer (most likely not working: not tested yet). The rest of the renderer seems to be unaffected, though, which is good.
2022-05-04 05:07:27 +00:00
#include "QF/Vulkan/qf_iqm.h"
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
#include "QF/Vulkan/qf_lighting.h"
[vulkan] Make a lot of progress for brush models Light maps are maybe updating, but as nothing is actually rendered yet, it's hard to tell.
2021-01-19 16:25:54 +00:00
#include "QF/Vulkan/qf_lightmap.h"
#include "QF/Vulkan/qf_main.h"
[vulkan] Move matrices into per-frame buffers This should fix the horrid frame rate dependent behavior of the view model. They are also in their own descriptor set so they can be easily shared between pipelines. This has been verified to work for Draw.
2021-12-08 06:28:21 +00:00
#include "QF/Vulkan/qf_matrices.h"
[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
#include "QF/Vulkan/qf_output.h"
[vulkan] Upload palette as a 16x16 image It turns out my approach to alias skin coloring just doesn't work for the quake data due to the color curves not having a linear relationship, especially the bottom colors.
2022-11-15 00:26:17 +00:00
#include "QF/Vulkan/qf_palette.h"
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
#include "QF/Vulkan/qf_particles.h"
[vulkan] Rename the renderpass files I plan on moving the current hard-coded render pass creation from vulkan_vid_common and this maintains the (possibly silly) naming convention).
2022-05-30 03:10:00 +00:00
#include "QF/Vulkan/qf_renderpass.h"
[vulkan] Use a buffer for entity transform and color data This allows the use of an entity id to index into the entity data and fetch the transform and colormod data in the vertex shader, thus making instanced rendering possible. Non-world brush entities are still not rendered, but the world entity is using both the entity data buffer and entid buffer.
2022-05-24 15:17:57 +00:00
#include "QF/Vulkan/qf_scene.h"
[vulkan] Load sprite model data The vertices and frame images are loaded into the one memory object, with the vertices first followed by the images. The vertices are 2D xy+uv sets meant to be applied to the model transform frame, and are pre-computed for the sprite size (this part does support sprites with varying frame image sizes). The frame images are loaded into one image with each frame on its own layer. This will cause some problems if any sprites with varying frame image sizes are found, but the three sprites in quake are all uniform size.
2021-12-14 01:02:35 +00:00
#include "QF/Vulkan/qf_sprite.h"
[vulkan] Generate triangle fans for bsp models They're not uploaded to the card yet, but the basics seem to be working.
2021-01-20 06:11:50 +00:00
#include "QF/Vulkan/qf_texture.h"
[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
#include "QF/Vulkan/qf_translucent.h"
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
#include "QF/Vulkan/qf_vid.h"
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
#include "QF/Vulkan/capture.h"
Create command pool and frame timing fences Nothing is actually done yet, so the reported fps is around 172k (yes, k), but startup and shutdown seems to be clean (yay validation layers).
2020-02-16 13:45:27 +00:00
#include "QF/Vulkan/command.h"
[vulkan] Label renderpass and subpass sections This makes finding the relevant commands in render doc much much easier.
2022-05-07 03:38:31 +00:00
#include "QF/Vulkan/debug.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
#include "QF/Vulkan/device.h"
Rework much of the Vulkan array handling So much for all those little wrappers hiding the device. Some survived, but mostly just the bigger things like device, swapchain, etc.
2020-02-17 11:29:35 +00:00
#include "QF/Vulkan/image.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
#include "QF/Vulkan/instance.h"
[renderer] Clean up FOV and viewport handling Viewport and FOV updates are now separate so updating one doesn't cause recalculations of the other. Also, perspective setup is now done directly from the tangents of the half angles for fov_x and fov_y making the renderers independent of fov/aspect mode. I imagine things are a bit of a mess with view size changes, and especially screen size changes (not supported yet anyway), and vulkan winds up updating its projection matrices every frame, but everything that's expected to work does (vulkan errors out for fisheye or warp due to frame buffer creation not being supported yet).
2022-03-30 05:55:32 +00:00
#include "QF/Vulkan/projection.h"
[vulkan] Free the staging buffer's command buffers Since the staging buffer allocates the command buffers it uses, it needs to free them when it is freed. I think I was confused by the validation layers not complaining about unfreed buffers when shutting down, but that's because destroying the pool (during program shutdown, when the validation layers would complain) frees all the buffers. Thus, due to staging buffers being created and destroyed during the level load process, (rather large) command buffers were piling up like imps in a Doom level. In the process, it was necessary to rearrange some of the shutdown code because vulkan_vid_render_shutdown destroys the shared command pool, but the pool is required for freeing the command buffers, but there was a minor mess of long-lived staging buffers being freed afterwards. That didn't end particularly well.
2022-05-13 01:19:08 +00:00
#include "QF/Vulkan/staging.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
#include "QF/Vulkan/swapchain.h"
[video] Use views instead of conwidth and conheight conwidth and conheight have been moved into vid.conview (probably change the name at some time), and scr_vrect has been replaced by a view as well. This makes it much easier to create 2d elements that follow the screen size (taking advantage of a view's gravity) which will, in the end, make changing the window size easier.
2021-07-10 09:04:34 +00:00
#include "QF/ui/view.h"
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
[renderer] Support multiple entity queues While there's currently only the one still, this will allow the entities to be multiply queued for multi-pass rendering (eg, shadows). As the avoidance of putting an entity in the same queue more than once relies on the entity id, all entities now come from the scene (which is stored in cl_world in the client code for nq and qw), thus the extensive changes in the clients.
2022-03-04 16:48:10 +00:00
#include "QF/scene/entity.h"
[renderer] Use scene_t to set the model data This replaces *_NewMap with *_NewScene and adds SCR_NewScene to handle loading a new map (for quake) in the renderer, and will eventually be how any new scene is loaded.
2022-05-05 05:41:46 +00:00
#include "QF/scene/scene.h"
[renderer] Support multiple entity queues While there's currently only the one still, this will allow the entities to be multiply queued for multi-pass rendering (eg, shadows). As the avoidance of putting an entity in the same queue more than once relies on the entity id, all entities now come from the scene (which is stored in cl_world in the client code for nq and qw), thus the extensive changes in the clients.
2022-03-04 16:48:10 +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
#include "mod_internal.h"
#include "r_internal.h"
Move vid callbacks into vid_internal Currently segfaults because viddef is an alias for *r_data->vid, which has not yet been initialized (chicken and egg).
2019-07-08 04:40:29 +00:00
#include "vid_internal.h"
Separate render and presentation initialization This paves the way for clean initialization of the Vulkan renderer, and very much cleans up the older renderer initialization code as gl and sw are no longer intertwined.
2019-07-08 16:00:47 +00:00
#include "vid_vulkan.h"
[vulkan] Make script support objects more private This will help keep changes to the scripting system localized once things are further cleaned up.
2022-11-24 14:44:07 +00:00
#include "vulkan/vkparse.h"
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
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
static vulkan_ctx_t *vulkan_ctx;
Separate render and presentation initialization This paves the way for clean initialization of the Vulkan renderer, and very much cleans up the older renderer initialization code as gl and sw are no longer intertwined.
2019-07-08 16:00:47 +00:00
[particles] Create a psystem object This takes care of the global variables to a point (there is still the global struct shared between the non-vulkan renderers), but it also takes care of glsl's points-only rendering.
2021-12-19 05:47:25 +00:00
static struct psystem_s *
vulkan_ParticleSystem (void)
{
return Vulkan_ParticleSystem (vulkan_ctx);
}
Correct extension handling I had missed a critical bit from the cookbook.
2019-07-10 04:16:46 +00:00
static void
vulkan_R_Init (void)
{
[vulkan] Create a staging buffer struct And move the barrier prefabs into a more convenient place.
2021-01-10 16:24:15 +00:00
Vulkan_CreateStagingBuffers (vulkan_ctx);
[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_CreateFrames (vulkan_ctx);
[vulkan] Rearrange init code in preparation for resizing I've found and mostly isolated the parts of the code that will be affected by window resizing, minus pipelines but they use dynamic viewport and scissor settings and thus shouldn't be affected so long as the swapchain format doesn't change (how does that happen?)
2022-09-26 00:52:14 +00:00
Vulkan_Texture_Init (vulkan_ctx);
[vulkan] Upload palette as a 16x16 image It turns out my approach to alias skin coloring just doesn't work for the quake data due to the color curves not having a linear relationship, especially the bottom colors.
2022-11-15 00:26:17 +00:00
Vulkan_Palette_Init (vulkan_ctx, vid.palette);
[vulkan] Rearrange init code in preparation for resizing I've found and mostly isolated the parts of the code that will be affected by window resizing, minus pipelines but they use dynamic viewport and scissor settings and thus shouldn't be affected so long as the swapchain format doesn't change (how does that happen?)
2022-09-26 00:52:14 +00:00
Vulkan_CreateSwapchain (vulkan_ctx);
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
Vulkan_CreateCapture (vulkan_ctx);
[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
[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
Vulkan_CreateRenderPasses (vulkan_ctx);
[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
Vulkan_Output_Init (vulkan_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
[vulkan] Move matrices into per-frame buffers This should fix the horrid frame rate dependent behavior of the view model. They are also in their own descriptor set so they can be easily shared between pipelines. This has been verified to work for Draw.
2021-12-08 06:28:21 +00:00
Vulkan_Matrix_Init (vulkan_ctx);
[vulkan] Use a buffer for entity transform and color data This allows the use of an entity id to index into the entity data and fetch the transform and colormod data in the vertex shader, thus making instanced rendering possible. Non-world brush entities are still not rendered, but the world entity is using both the entity data buffer and entid buffer.
2022-05-24 15:17:57 +00:00
Vulkan_Scene_Init (vulkan_ctx);
[vulkan] Start work on alias model rendering
2021-01-26 11:58:24 +00:00
Vulkan_Alias_Init (vulkan_ctx);
[vulkan] Make a lot of progress for brush models Light maps are maybe updating, but as nothing is actually rendered yet, it's hard to tell.
2021-01-19 16:25:54 +00:00
Vulkan_Bsp_Init (vulkan_ctx);
[vulkan] Get IQM rendering working The bones aren't animated yet (and I realized I made the mistake of thinking the bone buffer was per-model when it's really per-instance (I think this mistake is in the rest of QF, too)), skin rendering is a mess, need to default vertex attributes that aren't in the model... Still, it's quite satisfying seeing Mr Fixit on screen again :) I wound up moving the pipeline spec in with the rest of the pipelines as the system isn't really ready for separating them.
2022-05-07 01:08:46 +00:00
Vulkan_IQM_Init (vulkan_ctx);
[vulkan] Start work on particles for Vulkan This gets the pipelines loaded (and unloaded on shutdown). Probably the easy part :P. Still need to sort out the command buffers, synchronization, and particle generation (and probably a bunch else that's not coming to mind).
2021-12-16 14:17:01 +00:00
Vulkan_Particles_Init (vulkan_ctx);
[vulkan] Implement the sprite render passes It turned out the bindless approach wouldn't work too well for my design of the sprite objects, but I don't think that's a big issue at this stage (and it seems bindless is causing problems for brush/alias rendering via renderdoc and on my versa pro). However, I have figured out how to make effective use of descriptor sets (finally :P). The actual normal still needs checking, but the sprites are currently unlit so not an issue at this stage.
2021-12-14 16:22:05 +00:00
Vulkan_Sprite_Init (vulkan_ctx);
[vulkan] Make a start on the 2D pipeline Short wrappers for Draw functins are in vid_render_vulkan.c so the vulkan context can be passed on to the actual functions. The 2D shaders are set up similar to those in glsl, but with full 32-bit color (rgba) support instead of paletted. However, the textures are not loaded yet, nor is anything bound.
2021-01-10 06:52:27 +00:00
Vulkan_Draw_Init (vulkan_ctx);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
Vulkan_Lighting_Init (vulkan_ctx);
[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
Vulkan_Translucent_Init (vulkan_ctx);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
Vulkan_Compose_Init (vulkan_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
[vulkan] Initialize skins This allows the qw client to run with Vulkan.
2021-03-19 13:53:23 +00:00
Skin_Init ();
Create and destroy render pass and frame buffers
2020-02-18 08:18:37 +00:00
[vulkan] Get the 2D pipeline up and running First pixels! This was a nightmare of little issues that the validation layers couldn't help with: incorrect input assembly, incorrect vertex attribute specs. Though the layers did help with getting the queues working. Still, lots of work to go but this is a major breakthrough as I now have access to visual debugging for textures and the like.
2021-01-12 02:27:41 +00:00
SCR_Init ();
Create command pool and frame timing fences Nothing is actually done yet, so the reported fps is around 172k (yes, k), but startup and shutdown seems to be clean (yay validation layers).
2020-02-16 13:45:27 +00:00
}
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
static void
vulkan_R_ClearState (void)
{
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
QFV_DeviceWaitIdle (vulkan_ctx->device);
[renderer] move r_worldentity and r_viewleaf into refdef More cleanup of globals that seem to be quake specific.
2022-03-14 06:27:43 +00:00
r_refdef.worldmodel = 0;
[vulkan] Make a lot of progress for brush models Light maps are maybe updating, but as nothing is actually rendered yet, it's hard to tell.
2021-01-19 16:25:54 +00:00
R_ClearDlights ();
[particles] Merge particle spawning into client After yesterday's crazy marathon editing all the particles files, and starting to do another big change to them today, I realized that I really do need to merge them down. All the actual spawning is now in the client library (though particle insertion will need to be moved). GLSL particle rendering is semi-broken in that it now does only points (until I come up with a way to select between points and quads (probably a context object, which I need anyway for Vulkan)).
2021-12-19 04:08:39 +00:00
R_ClearParticles ();
[vulkan] Clear lights when the scene is cleared Fixes a segfault when shutting down my test program.
2022-05-07 03:12:02 +00:00
Vulkan_LoadLights (0, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
vulkan_R_LoadSkys (const char *skyname)
{
[vulkan] Implement sky box loading and rendering Loading is broken for multi-file image sets due to the way images are loaded (this needs some thought for making it effecient), but the Blender environment map loading works.
2021-03-25 06:54:34 +00:00
Vulkan_LoadSkys (skyname, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
[renderer] Use scene_t to set the model data This replaces *_NewMap with *_NewScene and adds SCR_NewScene to handle loading a new map (for quake) in the renderer, and will eventually be how any new scene is loaded.
2022-05-05 05:41:46 +00:00
vulkan_R_NewScene (scene_t *scene)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
[renderer] Use scene_t to set the model data This replaces *_NewMap with *_NewScene and adds SCR_NewScene to handle loading a new map (for quake) in the renderer, and will eventually be how any new scene is loaded.
2022-05-05 05:41:46 +00:00
Vulkan_NewScene (scene, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
[qw] Clean up netgraph somewhat The renderer's LineGraph now takes a height parameter, and netgraph now uses cl_* cvars instead of r_* (which never really made sense), including it's own height cvar (the render graphs still use r_graphheight).
2021-07-11 01:59:27 +00:00
vulkan_R_LineGraph (int x, int y, int *h_vals, int count, int height)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
[vulkan] Implement line graph rendering I should probably just use the line rendering for all renderers and pull the graph drawing out to the client code.
2022-11-10 12:19:01 +00:00
Vulkan_LineGraph (x, y, h_vals, count, height, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
[renderer] Add a cell-based character buffer This is intended for the built-in 8x8 bitmap characters and quake's "conchars", but could potentially be used for any simple (non-composed characters) mono-spaced font. Currently, the buffers can be created, destroyed, cleared, scrolled vertically in either direction, and rendered to the screen in a single blast. One of the reasons for creating the buffer is to make it so scaling can be supported in the sw renderer.
2022-09-15 05:24:33 +00:00
static void
vulkan_Draw_CharBuffer (int x, int y, draw_charbuffer_t *buffer)
{
Vulkan_Draw_CharBuffer (x, y, buffer, vulkan_ctx);
}
[console] Resurrect console scaling Currently only for gl/glsl/vulkan. However, rather than futzing with con_width and con_height (and trying to guess good values), con_scale (currently an integer) gives consistent pixel scaling regardless of window size.
2022-11-13 13:23:56 +00:00
static void
vulkan_Draw_SetScale (int scale)
{
vulkan_ctx->twod_scale = max (1, scale);
}
[vulkan] Make a start on the 2D pipeline Short wrappers for Draw functins are in vid_render_vulkan.c so the vulkan context can be passed on to the actual functions. The 2D shaders are set up similar to those in glsl, but with full 32-bit color (rgba) support instead of paletted. However, the textures are not loaded yet, nor is anything bound.
2021-01-10 06:52:27 +00:00
static void
vulkan_Draw_Character (int x, int y, unsigned ch)
{
Vulkan_Draw_Character (x, y, ch, vulkan_ctx);
}
static void
vulkan_Draw_String (int x, int y, const char *str)
{
Vulkan_Draw_String (x, y, str, vulkan_ctx);
}
static void
vulkan_Draw_nString (int x, int y, const char *str, int count)
{
Vulkan_Draw_nString (x, y, str, count, vulkan_ctx);
}
static void
vulkan_Draw_AltString (int x, int y, const char *str)
{
Vulkan_Draw_AltString (x, y, str, vulkan_ctx);
}
static void
vulkan_Draw_ConsoleBackground (int lines, byte alpha)
{
Vulkan_Draw_ConsoleBackground (lines, alpha, vulkan_ctx);
}
static void
vulkan_Draw_Crosshair (void)
{
Vulkan_Draw_Crosshair (vulkan_ctx);
}
static void
vulkan_Draw_CrosshairAt (int ch, int x, int y)
{
Vulkan_Draw_CrosshairAt (ch, x, y, vulkan_ctx);
}
static void
vulkan_Draw_TileClear (int x, int y, int w, int h)
{
Vulkan_Draw_TileClear (x, y, w, h, vulkan_ctx);
}
static void
vulkan_Draw_Fill (int x, int y, int w, int h, int c)
{
Vulkan_Draw_Fill (x, y, w, h, c, vulkan_ctx);
}
[render] Add basic 2d line drawing The software renderer uses Bresenham's line slice algorithm as presented by Michael Abrash in his Graphics Programming Black Book Special Edition with the serial numbers filed off (as such, more just so *I* can read the code easily), along with the Chen-Sutherland line clipping algorithm. The other renderers were more or less trivial in comparison.
2022-05-28 09:14:26 +00:00
static void
vulkan_Draw_Line (int x0, int y0, int x1, int y1, int c)
{
Vulkan_Draw_Line (x0, y0, x1, y1, c, vulkan_ctx);
}
[vulkan] Make a start on the 2D pipeline Short wrappers for Draw functins are in vid_render_vulkan.c so the vulkan context can be passed on to the actual functions. The 2D shaders are set up similar to those in glsl, but with full 32-bit color (rgba) support instead of paletted. However, the textures are not loaded yet, nor is anything bound.
2021-01-10 06:52:27 +00:00
static void
vulkan_Draw_TextBox (int x, int y, int width, int lines, byte alpha)
{
Vulkan_Draw_TextBox (x, y, width, lines, alpha, vulkan_ctx);
}
static void
vulkan_Draw_FadeScreen (void)
{
Vulkan_Draw_FadeScreen (vulkan_ctx);
}
static void
vulkan_Draw_BlendScreen (quat_t color)
{
Vulkan_Draw_BlendScreen (color, vulkan_ctx);
}
Create command pool and frame timing fences Nothing is actually done yet, so the reported fps is around 172k (yes, k), but startup and shutdown seems to be clean (yay validation layers).
2020-02-16 13:45:27 +00:00
static qpic_t *
vulkan_Draw_CachePic (const char *path, qboolean alpha)
{
[vulkan] Make a start on the 2D pipeline Short wrappers for Draw functins are in vid_render_vulkan.c so the vulkan context can be passed on to the actual functions. The 2D shaders are set up similar to those in glsl, but with full 32-bit color (rgba) support instead of paletted. However, the textures are not loaded yet, nor is anything bound.
2021-01-10 06:52:27 +00:00
return Vulkan_Draw_CachePic (path, alpha, vulkan_ctx);
Create command pool and frame timing fences Nothing is actually done yet, so the reported fps is around 172k (yes, k), but startup and shutdown seems to be clean (yay validation layers).
2020-02-16 13:45:27 +00:00
}
[vulkan] Make a start on the 2D pipeline Short wrappers for Draw functins are in vid_render_vulkan.c so the vulkan context can be passed on to the actual functions. The 2D shaders are set up similar to those in glsl, but with full 32-bit color (rgba) support instead of paletted. However, the textures are not loaded yet, nor is anything bound.
2021-01-10 06:52:27 +00:00
static void
vulkan_Draw_UncachePic (const char *path)
{
Vulkan_Draw_UncachePic (path, vulkan_ctx);
}
Create command pool and frame timing fences Nothing is actually done yet, so the reported fps is around 172k (yes, k), but startup and shutdown seems to be clean (yay validation layers).
2020-02-16 13:45:27 +00:00
static qpic_t *
vulkan_Draw_MakePic (int width, int height, const byte *data)
{
[vulkan] Make a start on the 2D pipeline Short wrappers for Draw functins are in vid_render_vulkan.c so the vulkan context can be passed on to the actual functions. The 2D shaders are set up similar to those in glsl, but with full 32-bit color (rgba) support instead of paletted. However, the textures are not loaded yet, nor is anything bound.
2021-01-10 06:52:27 +00:00
return Vulkan_Draw_MakePic (width, height, data, vulkan_ctx);
}
static void
vulkan_Draw_DestroyPic (qpic_t *pic)
{
Vulkan_Draw_DestroyPic (pic, vulkan_ctx);
}
static qpic_t *
vulkan_Draw_PicFromWad (const char *name)
{
return Vulkan_Draw_PicFromWad (name, vulkan_ctx);
}
static void
vulkan_Draw_Pic (int x, int y, qpic_t *pic)
{
Vulkan_Draw_Pic (x, y, pic, vulkan_ctx);
}
static void
vulkan_Draw_Picf (float x, float y, qpic_t *pic)
{
Vulkan_Draw_Picf (x, y, pic, vulkan_ctx);
}
static void
vulkan_Draw_SubPic (int x, int y, qpic_t *pic, int srcx, int srcy, int width, int height)
{
Vulkan_Draw_SubPic (x, y, pic, srcx, srcy, width, height, vulkan_ctx);
Correct extension handling I had missed a critical bit from the cookbook.
2019-07-10 04:16:46 +00:00
}
[renderer] Add fontid to Draw_AddFont and Draw_FontString It's not used yet, but the vulkan draw implementation will eventually support multiple fonts being loaded (and rendered at a time).
2022-10-02 23:58:27 +00:00
static int
[renderer] Add Draw_AddFont for registering a font It's implemented only in the Vulkan renderer, partly because there's a lot of experimenting going on with it, but the glyphs do get transferred to the GPU (checked in render doc). No rendering is done yet: still thinking about whether to do a quick-and-dirty test, or to add HarfBuzz immediately, and the design surrounding that.
2022-08-31 10:23:30 +00:00
vulkan_Draw_AddFont (struct rfont_s *font)
{
[renderer] Add fontid to Draw_AddFont and Draw_FontString It's not used yet, but the vulkan draw implementation will eventually support multiple fonts being loaded (and rendered at a time).
2022-10-02 23:58:27 +00:00
return Vulkan_Draw_AddFont (font, vulkan_ctx);
[renderer] Add Draw_AddFont for registering a font It's implemented only in the Vulkan renderer, partly because there's a lot of experimenting going on with it, but the glyphs do get transferred to the GPU (checked in render doc). No rendering is done yet: still thinking about whether to do a quick-and-dirty test, or to add HarfBuzz immediately, and the design surrounding that.
2022-08-31 10:23:30 +00:00
}
[renderer] Add stubs for Draw_FontString Draw_FontString is for font-based text rendering. Nothing is implemented at this stage.
2022-09-02 02:38:09 +00:00
static void
[renderer] Add fontid to Draw_AddFont and Draw_FontString It's not used yet, but the vulkan draw implementation will eventually support multiple fonts being loaded (and rendered at a time).
2022-10-02 23:58:27 +00:00
vulkan_Draw_FontString (int x, int y, int fontid, const char *str)
[renderer] Add stubs for Draw_FontString Draw_FontString is for font-based text rendering. Nothing is implemented at this stage.
2022-09-02 02:38:09 +00:00
{
[renderer] Add fontid to Draw_AddFont and Draw_FontString It's not used yet, but the vulkan draw implementation will eventually support multiple fonts being loaded (and rendered at a time).
2022-10-02 23:58:27 +00:00
Vulkan_Draw_FontString (x, y, fontid, str, vulkan_ctx);
[renderer] Add stubs for Draw_FontString Draw_FontString is for font-based text rendering. Nothing is implemented at this stage.
2022-09-02 02:38:09 +00:00
}
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
static void
vulkan_begin_frame (void)
{
qfv_device_t *device = vulkan_ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
VkDevice dev = device->dev;
__auto_type frame = &vulkan_ctx->frames.a[vulkan_ctx->curFrame];
dfunc->vkWaitForFences (dev, 1, &frame->fence, VK_TRUE, 2000000000);
}
static void
vulkan_render_view (void)
{
for (size_t i = 0; i < vulkan_ctx->renderPasses.size; i++) {
__auto_type rp = vulkan_ctx->renderPasses.a[i];
__auto_type rpFrame = &rp->frames.a[vulkan_ctx->curFrame];
[vulkan] Move swap chain image acquisition to the output module Swap chain acquisition is part of final output handling. However, as the correct frame buffers are required for the render passes, the acquisition needs to be performed during the preoutput render pass. Window resize is still broken, but this is a big step towards fixing it.
2022-11-25 07:08:15 +00:00
// swapImageIndex may be updated by a render pass
uint32_t imageIndex = vulkan_ctx->swapImageIndex;
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
if (rp->framebuffers) {
[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
rpFrame->framebuffer = rp->framebuffers->a[imageIndex];
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
}
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
rp->draw (rpFrame);
}
}
[renderer] Move most of the scene rendering into r_screen r_screen isn't really the right place, but it gets the scene rendering out of the low-level renderers and will make it easier to sort out later, and hopefully easier to figure out a good design for vulkan.
2022-03-17 08:50:38 +00:00
static void
vulkan_draw_particles (struct psystem_s *psystem)
{
}
[renderer] Handle transparent surfaces Other than the view model (undecided on the approach) this has R_RenderView pretty much pulled out of the low level renderers. With this, I'll be able to focus on scene handling for a bit then getting shadows and fisheye working (again for fisheye).
2022-03-17 15:14:48 +00:00
static void
vulkan_draw_transparent (void)
{
}
[renderer] Get sw fisheye working again Again, gl/vulkan not working yet (on the assumption that sw would be trickier). Fisheye overrides water warp because updating the projection map every frame is far too expensive. I've added a post-process pass to the interface in order to hide the implementation details, but I'm not sure I'm happy about how the multi-pass rendering for cube maps is handled (or having the frame buffers as exposed as they are), but mainly because Vulkan will make implementation interesting.
2022-03-24 06:45:01 +00:00
static void
vulkan_post_process (framebuffer_t *src)
{
}
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
static void
[renderer] Get timegraph and zgraph working Only for sw and gl right now, but this sorts out the issues that prevented the graphs working at all.
2022-03-15 06:42:43 +00:00
vulkan_set_2d (int scaled)
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
{
[renderer] Clean up FOV and viewport handling Viewport and FOV updates are now separate so updating one doesn't cause recalculations of the other. Also, perspective setup is now done directly from the tangents of the half angles for fov_x and fov_y making the renderers independent of fov/aspect mode. I imagine things are a bit of a mess with view size changes, and especially screen size changes (not supported yet anyway), and vulkan winds up updating its projection matrices every frame, but everything that's expected to work does (vulkan errors out for fisheye or warp due to frame buffer creation not being supported yet).
2022-03-30 05:55:32 +00:00
//FIXME this should not be done every frame
__auto_type mctx = vulkan_ctx->matrix_context;
__auto_type mat = &mctx->matrices;
[console] Resurrect console scaling Currently only for gl/glsl/vulkan. However, rather than futzing with con_width and con_height (and trying to guess good values), con_scale (currently an integer) gives consistent pixel scaling regardless of window size.
2022-11-13 13:23:56 +00:00
int scale = vulkan_ctx->twod_scale;
[renderer] Clean up FOV and viewport handling Viewport and FOV updates are now separate so updating one doesn't cause recalculations of the other. Also, perspective setup is now done directly from the tangents of the half angles for fov_x and fov_y making the renderers independent of fov/aspect mode. I imagine things are a bit of a mess with view size changes, and especially screen size changes (not supported yet anyway), and vulkan winds up updating its projection matrices every frame, but everything that's expected to work does (vulkan errors out for fisheye or warp due to frame buffer creation not being supported yet).
2022-03-30 05:55:32 +00:00
[renderer] Remove the 1/2 pixel shift of the 2d screen It seemed like a good idea at the time, but it exacerbates pixel leakage in atlas textures that have no border pixels (even in nearest sampling modes).
2022-11-19 16:17:09 +00:00
float left = 0;
float top = 0;
[console] Resurrect console scaling Currently only for gl/glsl/vulkan. However, rather than futzing with con_width and con_height (and trying to guess good values), con_scale (currently an integer) gives consistent pixel scaling regardless of window size.
2022-11-13 13:23:56 +00:00
float right = left + vid.width / scale;
float bottom = top + vid.height / scale;
[vulkan] Shift the 2d view by 0.5 pixels in X and Y Lines drawn along the top and left edges were not displayed because they were just off screen.
2022-09-28 13:24:22 +00:00
QFV_Orthographic (mat->Projection2d, left, right, top, bottom, 0, 99999);
[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
mat->ScreenSize = (vec2f_t) { 1.0 / vid.width, 1.0 / vid.height };
[renderer] Clean up FOV and viewport handling Viewport and FOV updates are now separate so updating one doesn't cause recalculations of the other. Also, perspective setup is now done directly from the tangents of the half angles for fov_x and fov_y making the renderers independent of fov/aspect mode. I imagine things are a bit of a mess with view size changes, and especially screen size changes (not supported yet anyway), and vulkan winds up updating its projection matrices every frame, but everything that's expected to work does (vulkan errors out for fisheye or warp due to frame buffer creation not being supported yet).
2022-03-30 05:55:32 +00:00
mctx->dirty = mctx->frames.size;
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
}
static void
vulkan_end_frame (void)
{
qfv_device_t *device = vulkan_ctx->device;
VkDevice dev = device->dev;
qfv_devfuncs_t *dfunc = device->funcs;
qfv_queue_t *queue = &device->queue;
[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
uint32_t curFrame = vulkan_ctx->curFrame;
__auto_type frame = &vulkan_ctx->frames.a[curFrame];
uint32_t imageIndex = vulkan_ctx->swapImageIndex;
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
VkCommandBufferBeginInfo beginInfo
= { VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO };
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
__auto_type cmdBufs = (qfv_cmdbufferset_t) DARRAY_STATIC_INIT (4);
DARRAY_APPEND (&cmdBufs, frame->cmdBuffer);
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
dfunc->vkBeginCommandBuffer (frame->cmdBuffer, &beginInfo);
for (size_t i = 0; i < vulkan_ctx->renderPasses.size; i++) {
__auto_type rp = vulkan_ctx->renderPasses.a[i];
[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
__auto_type rpFrame = &rp->frames.a[curFrame];
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
if (rp->primary_commands) {
for (int j = 0; j < rpFrame->subpassCount; j++) {
__auto_type cmdSet = &rpFrame->subpassCmdSets[j];
size_t base = cmdBufs.size;
DARRAY_RESIZE (&cmdBufs, base + cmdSet->size);
memcpy (&cmdBufs.a[base], cmdSet->a,
cmdSet->size * sizeof (VkCommandBuffer));
}
continue;
}
[vulkan] Label renderpass and subpass sections This makes finding the relevant commands in render doc much much easier.
2022-05-07 03:38:31 +00:00
QFV_CmdBeginLabel (device, frame->cmdBuffer, rp->name, rp->color);
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
if (rpFrame->renderpass && rp->renderpass) {
[vulkan] Rework render pass setup This splits up render pass creation so that the creation of the various resources can be tailored to the needs of the actual render pass sub-system. In addition, it gets window resizing mostly working (just some problems with incorrect rendering).
2022-11-26 13:23:59 +00:00
VkRenderPassBeginInfo renderPassInfo = {
.sType = VK_STRUCTURE_TYPE_RENDER_PASS_BEGIN_INFO,
.renderPass = rp->renderpass,
.framebuffer = rp->framebuffers->a[imageIndex],
.renderArea = rp->renderArea,
.clearValueCount = rp->clearValues->size,
.pClearValues = rp->clearValues->a,
};
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
dfunc->vkCmdBeginRenderPass (frame->cmdBuffer, &renderPassInfo,
rpFrame->subpassContents);
for (int j = 0; j < rpFrame->subpassCount; j++) {
__auto_type cmdSet = &rpFrame->subpassCmdSets[j];
if (cmdSet->size) {
[vulkan] Label renderpass and subpass sections This makes finding the relevant commands in render doc much much easier.
2022-05-07 03:38:31 +00:00
QFV_CmdBeginLabel (device, frame->cmdBuffer,
rpFrame->subpassInfo[j].name,
rpFrame->subpassInfo[j].color);
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
dfunc->vkCmdExecuteCommands (frame->cmdBuffer,
cmdSet->size, cmdSet->a);
[vulkan] Label renderpass and subpass sections This makes finding the relevant commands in render doc much much easier.
2022-05-07 03:38:31 +00:00
QFV_CmdEndLabel (device, frame->cmdBuffer);
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
}
// reset for next time around
cmdSet->size = 0;
//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.
if (j < rpFrame->subpassCount - 1) {
dfunc->vkCmdNextSubpass (frame->cmdBuffer,
rpFrame->subpassContents);
}
}
dfunc->vkCmdEndRenderPass (frame->cmdBuffer);
} else {
for (int j = 0; j < rpFrame->subpassCount; j++) {
__auto_type cmdSet = &rpFrame->subpassCmdSets[j];
if (cmdSet->size) {
dfunc->vkCmdExecuteCommands (frame->cmdBuffer,
cmdSet->size, cmdSet->a);
}
// reset for next time around
cmdSet->size = 0;
}
}
[vulkan] Label renderpass and subpass sections This makes finding the relevant commands in render doc much much easier.
2022-05-07 03:38:31 +00:00
QFV_CmdEndLabel (device, frame->cmdBuffer);
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
}
if (vulkan_ctx->capture_callback) {
VkImage srcImage = vulkan_ctx->swapchain->images->a[imageIndex];
VkCommandBuffer cmd = QFV_CaptureImage (vulkan_ctx->capture, srcImage,
[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
curFrame);
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
dfunc->vkCmdExecuteCommands (frame->cmdBuffer, 1, &cmd);
}
dfunc->vkEndCommandBuffer (frame->cmdBuffer);
VkPipelineStageFlags waitStage
= VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
VkSubmitInfo submitInfo = {
VK_STRUCTURE_TYPE_SUBMIT_INFO, 0,
1, &frame->imageAvailableSemaphore, &waitStage,
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
cmdBufs.size, cmdBufs.a,
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
1, &frame->renderDoneSemaphore,
};
dfunc->vkResetFences (dev, 1, &frame->fence);
dfunc->vkQueueSubmit (queue->queue, 1, &submitInfo, frame->fence);
[vulkan] Support creating render passes with no render pass Sounds odd, but it's part of the problem with calling two different things with essentially the same name. The "high level" render pass in question may be a compute pass, or a complex series of (Vulkan) render passes and so won't create a Vulkan render pass for the "high level" render pass (I do need to come up with a better name for it).
2022-05-31 01:56:00 +00:00
DARRAY_CLEAR (&cmdBufs);
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
if (vulkan_ctx->capture_callback) {
//FIXME look into "threading" this rather than waiting here
dfunc->vkWaitForFences (device->dev, 1, &frame->fence, VK_TRUE,
1000000000ull);
vulkan_ctx->capture_callback (QFV_CaptureData (vulkan_ctx->capture,
[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
curFrame),
[renderer] Move frame rendering out a layer. This is a step towards high-level unification of the renderers, as far as possible keeping only actual low-level implementation details in the individual renderers (some higher level stuff, eg shadows, is expected to be per-renderer as some things are just not feasible to implement in all renderers). However, the idea is to move the high-level functionality into scene rendering.
2022-03-07 14:32:44 +00:00
vulkan_ctx->capture->extent.width,
vulkan_ctx->capture->extent.height);
vulkan_ctx->capture_callback = 0;
}
VkPresentInfoKHR presentInfo = {
VK_STRUCTURE_TYPE_PRESENT_INFO_KHR, 0,
1, &frame->renderDoneSemaphore,
1, &vulkan_ctx->swapchain->swapchain, &imageIndex,
0
};
dfunc->vkQueuePresentKHR (queue->queue, &presentInfo);
vulkan_ctx->curFrame++;
vulkan_ctx->curFrame %= vulkan_ctx->frames.size;
}
[renderer] Get sw fisheye working again Again, gl/vulkan not working yet (on the assumption that sw would be trickier). Fisheye overrides water warp because updating the projection map every frame is far too expensive. I've added a post-process pass to the interface in order to hide the implementation details, but I'm not sure I'm happy about how the multi-pass rendering for cube maps is handled (or having the frame buffers as exposed as they are), but mainly because Vulkan will make implementation interesting.
2022-03-24 06:45:01 +00:00
static framebuffer_t *
vulkan_create_cube_map (int size)
{
[vulkan] Safely ignore fisheye and water warp I didn't like the abort (especially having pushed it to master). This takes care of things until I can get them implemented properly (hopefully soon).
2022-04-01 07:49:39 +00:00
return 0;
[renderer] Get sw fisheye working again Again, gl/vulkan not working yet (on the assumption that sw would be trickier). Fisheye overrides water warp because updating the projection map every frame is far too expensive. I've added a post-process pass to the interface in order to hide the implementation details, but I'm not sure I'm happy about how the multi-pass rendering for cube maps is handled (or having the frame buffers as exposed as they are), but mainly because Vulkan will make implementation interesting.
2022-03-24 06:45:01 +00:00
}
[renderer] Move to using dynamic frame buffers For now, OpenGL and Vulkan renderers are broken as I focused on getting the software renderer working (which was quite tricky to get right). This fixes a couple of issues: the segfault when warping the screen (due to the scene rendering move invalidating the warp buffer), and warp always having 320x200 resolution. There's still the problem of the effect being too subtle at high resolution, but that's just a matter of updating the tables and tweaking the code in D_WarpScreen. Another issue is the Draw functions should probably write directly to the main frame buffer or even one passed in as a parameter. This would remove the need for binding the main buffer at the beginning and end of the frame.
2022-03-24 03:22:27 +00:00
static framebuffer_t *
vulkan_create_frame_buffer (int width, int height)
{
[vulkan] Safely ignore fisheye and water warp I didn't like the abort (especially having pushed it to master). This takes care of things until I can get them implemented properly (hopefully soon).
2022-04-01 07:49:39 +00:00
return 0;
[renderer] Move to using dynamic frame buffers For now, OpenGL and Vulkan renderers are broken as I focused on getting the software renderer working (which was quite tricky to get right). This fixes a couple of issues: the segfault when warping the screen (due to the scene rendering move invalidating the warp buffer), and warp always having 320x200 resolution. There's still the problem of the effect being too subtle at high resolution, but that's just a matter of updating the tables and tweaking the code in D_WarpScreen. Another issue is the Draw functions should probably write directly to the main frame buffer or even one passed in as a parameter. This would remove the need for binding the main buffer at the beginning and end of the frame.
2022-03-24 03:22:27 +00:00
}
[renderer] Add function to destroy frame buffers Needed for window resizing for fisheye and warp buffers (main buffers will be taken care of by the drivers).
2022-09-21 14:47:14 +00:00
static void
vulkan_destroy_frame_buffer (framebuffer_t *framebuffer)
{
}
[renderer] Move to using dynamic frame buffers For now, OpenGL and Vulkan renderers are broken as I focused on getting the software renderer working (which was quite tricky to get right). This fixes a couple of issues: the segfault when warping the screen (due to the scene rendering move invalidating the warp buffer), and warp always having 320x200 resolution. There's still the problem of the effect being too subtle at high resolution, but that's just a matter of updating the tables and tweaking the code in D_WarpScreen. Another issue is the Draw functions should probably write directly to the main frame buffer or even one passed in as a parameter. This would remove the need for binding the main buffer at the beginning and end of the frame.
2022-03-24 03:22:27 +00:00
static void
vulkan_bind_framebuffer (framebuffer_t *framebuffer)
{
}
[renderer] Clean up post processing While it's not where I want it to be, it at least now no longer messes with frame buffer binding or the view ports. This involved switching around buffers in D_WarpScreen so that the main buffer could be bound before post-processing.
2022-03-25 15:29:34 +00:00
static void
vulkan_set_viewport (const vrect_t *view)
{
}
[renderer] Clean up FOV and viewport handling Viewport and FOV updates are now separate so updating one doesn't cause recalculations of the other. Also, perspective setup is now done directly from the tangents of the half angles for fov_x and fov_y making the renderers independent of fov/aspect mode. I imagine things are a bit of a mess with view size changes, and especially screen size changes (not supported yet anyway), and vulkan winds up updating its projection matrices every frame, but everything that's expected to work does (vulkan errors out for fisheye or warp due to frame buffer creation not being supported yet).
2022-03-30 05:55:32 +00:00
static void
vulkan_set_fov (float x, float y)
{
if (!vulkan_ctx || !vulkan_ctx->matrix_context) {
return;
}
__auto_type mctx = vulkan_ctx->matrix_context;
__auto_type mat = &mctx->matrices;
QFV_PerspectiveTan (mat->Projection3d, x, y);
mctx->dirty = mctx->frames.size;
}
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
static int
is_bgr (VkFormat format)
{
return (format >= VK_FORMAT_B8G8R8A8_UNORM
&& format <= VK_FORMAT_B8G8R8A8_SRGB);
}
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
static void
capture_screenshot (const byte *data, int width, int height)
{
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
int count = width * height;
tex_t *tex = malloc (sizeof (tex_t) + count * 3);
if (tex) {
tex->data = (byte *) (tex + 1);
[image] Make WritePNG take settings from tex_t This means that a tex_t object is passed in instead of just raw bytes and width and height, but it means the texture can specify whether it's flipped or uses BGR instead of RGB. This fixes the upside down screenshots for vulkan.
2022-03-31 11:00:13 +00:00
tex->flagbits = 0;
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
tex->width = width;
tex->height = height;
tex->format = tex_rgb;
tex->palette = 0;
[image] Make WritePNG take settings from tex_t This means that a tex_t object is passed in instead of just raw bytes and width and height, but it means the texture can specify whether it's flipped or uses BGR instead of RGB. This fixes the upside down screenshots for vulkan.
2022-03-31 11:00:13 +00:00
tex->flagbits = 0;
tex->loaded = 1;
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
[vulkan] Use vkCmdCopyImageToBuffer for screenshot capture I had missed that vkCmdCopyImage requires the source and destination images to have exactly the same size, and I guess assumed that the swapchain images would always be the size they said they were, but this is not the case for tiled-optimal images. However, vkCmdCopyImageToBuffer does the right thing regardless of the source image size. This fixes the skewed screenshots when the window size is not a multiple of 8 (for me, might differ for others).
2022-09-26 06:54:20 +00:00
if (is_bgr (vulkan_ctx->swapchain->format)) {
[image] Make WritePNG take settings from tex_t This means that a tex_t object is passed in instead of just raw bytes and width and height, but it means the texture can specify whether it's flipped or uses BGR instead of RGB. This fixes the upside down screenshots for vulkan.
2022-03-31 11:00:13 +00:00
tex->bgr = 1;
}
const byte *src = data;
byte *dst = tex->data;
for (int count = width * height; count-- > 0; ) {
*dst++ = *src++;
*dst++ = *src++;
*dst++ = *src++;
src++;
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
}
}
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
capfunc_t callback = vulkan_ctx->capture_complete;
callback (tex, vulkan_ctx->capture_complete_data);;
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
}
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
static void
vulkan_capture_screen (capfunc_t callback, void *data)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
if (!vulkan_ctx->capture) {
[renderer] Merge screenshot code as much as possible Only CaptureBGR is per-renderer as the rest of the screenshot code uses it to do the actual capture (which is target dependent). Vulkan is currently broken due to capture being an asynchronous process and the rest of the code expecting capture to be synchronous (also, bgr vs rgb). The best thing is all renderers now write the same format (currently png).
2022-03-07 05:39:47 +00:00
Sys_Printf ("Capture not supported\n");
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
callback (0, data);
return;
[vulkan] Implement screenshot Finally, I can brag about my progress on irc :)
2021-03-24 10:20:53 +00:00
}
vulkan_ctx->capture_callback = capture_screenshot;
[renderer] Make screen capture support asynchronous operation This fixes (*ahem*) the vulkan renderer segfaulting when attempting to take a screenshot. However, the image is upside down. Also, remote snapshots and demo capture are broken for the moment.
2022-03-31 10:07:15 +00:00
vulkan_ctx->capture_complete = callback;
vulkan_ctx->capture_complete_data = data;
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
[model] Clean up the globals around model loading Covers only the generic load code (alias etc to follow), but this should take care of a lot of issues in the future.
2021-02-01 05:39:00 +00:00
vulkan_Mod_LoadLighting (model_t *mod, bsp_t *bsp)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
[model] Clean up the globals around model loading Covers only the generic load code (alias etc to follow), but this should take care of a lot of issues in the future.
2021-02-01 05:39:00 +00:00
Vulkan_Mod_LoadLighting (mod, bsp, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
[model] Clean up the globals around model loading Covers only the generic load code (alias etc to follow), but this should take care of a lot of issues in the future.
2021-02-01 05:39:00 +00:00
vulkan_Mod_SubdivideSurface (model_t *mod, msurface_t *fa)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
}
static void
[model] Clean up the globals around model loading Covers only the generic load code (alias etc to follow), but this should take care of a lot of issues in the future.
2021-02-01 05:39:00 +00:00
vulkan_Mod_ProcessTexture (model_t *mod, texture_t *tx)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
[model] Clean up the globals around model loading Covers only the generic load code (alias etc to follow), but this should take care of a lot of issues in the future.
2021-02-01 05:39:00 +00:00
Vulkan_Mod_ProcessTexture (mod, tx, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
[model] Clean up the globals for alias models
2021-02-01 12:11:45 +00:00
vulkan_Mod_MakeAliasModelDisplayLists (mod_alias_ctx_t *alias_ctx,
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
void *_m, int _s, int extra)
{
[model] Clean up the globals for alias models
2021-02-01 12:11:45 +00:00
Vulkan_Mod_MakeAliasModelDisplayLists (alias_ctx, _m, _s, extra,
vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
[model] Make alias skin loading a batch operation Really, this won't make all that much difference because alias models with more than one skin are quite rare, and those with animated skin groups are even rarer. However, for those models that do have more than one skin, it will allow for reduced allocation overheads, and when supported (glsl, vulkan, maybe gl), loading all the skins into an array texture (since all skins are the same size, though external skins may vary), but that's not implemented yet, this just wraps the old one skin at a time code.
2022-04-04 06:38:27 +00:00
static void
vulkan_Mod_LoadAllSkins (mod_alias_ctx_t *alias_ctx)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
[model] Make alias skin loading a batch operation Really, this won't make all that much difference because alias models with more than one skin are quite rare, and those with animated skin groups are even rarer. However, for those models that do have more than one skin, it will allow for reduced allocation overheads, and when supported (glsl, vulkan, maybe gl), loading all the skins into an array texture (since all skins are the same size, though external skins may vary), but that's not implemented yet, this just wraps the old one skin at a time code.
2022-04-04 06:38:27 +00:00
Vulkan_Mod_LoadAllSkins (alias_ctx, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
[model] Clean up the globals for alias models
2021-02-01 12:11:45 +00:00
vulkan_Mod_FinalizeAliasModel (mod_alias_ctx_t *alias_ctx)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
[model] Clean up the globals for alias models
2021-02-01 12:11:45 +00:00
Vulkan_Mod_FinalizeAliasModel (alias_ctx, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
[model] Clean up the globals for alias models
2021-02-01 12:11:45 +00:00
vulkan_Mod_LoadExternalSkins (mod_alias_ctx_t *alias_ctx)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
}
static void
vulkan_Mod_IQMFinish (model_t *mod)
{
[vulkan] Add support for IQM models Despite the base IQM specification not supporting blend-shapes, I think IQM will become the basis for QF's generic model representation (at least for the more advanced renderers). After my experience with .mu models (KSP) and unity mesh objects (both normal and skinned), and reviewing the IQM spec, it looks like with the addition of support for blend-shapes, IQM is actually pretty good. This is just the preliminary work to get standard IQM models loading in vulkan (seems to work, along with unloading), and they very basics into the renderer (most likely not working: not tested yet). The rest of the renderer seems to be unaffected, though, which is good.
2022-05-04 05:07:27 +00:00
Vulkan_Mod_IQMFinish (mod, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
[sprite] Separate model and texture loading As much as it can be since the texture data is interleaved with the model data in the files (I guess not that bad a design for 25 years ago with the tight memory constraints), but this paves the way for supporting sprites in Vulkan.
2021-12-13 23:36:19 +00:00
vulkan_Mod_SpriteLoadFrames (mod_sprite_ctx_t *sprite_ctx)
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
{
[vulkan] Load sprite model data The vertices and frame images are loaded into the one memory object, with the vertices first followed by the images. The vertices are 2D xy+uv sets meant to be applied to the model transform frame, and are pre-computed for the sprite size (this part does support sprites with varying frame image sizes). The frame images are loaded into one image with each frame on its own layer. This will cause some problems if any sprites with varying frame image sizes are found, but the three sprites in quake are all uniform size.
2021-12-14 01:02:35 +00:00
Vulkan_Mod_SpriteLoadFrames (sprite_ctx, vulkan_ctx);
[renderer] Stub out all the vulkan functions nq-x11 now gets through all three demos without crashing (but without rendering anything useful, though).
2021-01-18 03:46:06 +00:00
}
static void
vulkan_Skin_SetupSkin (struct skin_s *skin, int cmap)
{
}
static void
vulkan_Skin_ProcessTranslation (int cmap, const byte *translation)
{
}
static void
vulkan_Skin_InitTranslations (void)
{
}
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
static void
[video] Get 16 and 32 bit sw32 mostly working in x11 Lighting on alias models seems to be borked, and skies are borked in both sw renderers (seems to be nothing to do with this commit, though).
2021-07-10 15:09:41 +00:00
set_palette (void *data, const byte *palette)
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
{
[vulkan] Upload palette as a 16x16 image It turns out my approach to alias skin coloring just doesn't work for the quake data due to the color curves not having a linear relationship, especially the bottom colors.
2022-11-15 00:26:17 +00:00
if (vulkan_ctx->palette_context) {
Vulkan_Palette_Update (vulkan_ctx, palette);
}
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
}
static void
[video] Get 16 and 32 bit sw32 mostly working in x11 Lighting on alias models seems to be borked, and skies are borked in both sw renderers (seems to be nothing to do with this commit, though).
2021-07-10 15:09:41 +00:00
vulkan_vid_render_choose_visual (void *data)
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
{
Vulkan_CreateDevice (vulkan_ctx);
[vulkan] Fail gracefully if vulkan driver init fails Well, a little more gracefully than a segfault, at least.
2021-11-29 04:40:56 +00:00
if (!vulkan_ctx->device) {
Sys_Error ("Unable to create Vulkan device.%s",
[cvar] Make cvars properly typed This is an extremely extensive patch as it hits every cvar, and every usage of the cvars. Cvars no longer store the value they control, instead, they use a cexpr value object to reference the value and specify the value's type (currently, a null type is used for strings). Non-string cvars are passed through cexpr, allowing expressions in the cvars' settings. Also, cvars have returned to an enhanced version of the original (id quake) registration scheme. As a minor benefit, relevant code having direct access to the cvar-controlled variables is probably a slight optimization as it removed a pointer dereference, and the variables can be located for data locality. The static cvar descriptors are made private as an additional safety layer, though there's nothing stopping external modification via Cvar_FindVar (which is needed for adding listeners). While not used yet (partly due to working out the design), cvars can have a validation function. Registering a cvar allows a primary listener (and its data) to be specified: it will always be called first when the cvar is modified. The combination of proper listeners and direct access to the controlled variable greatly simplifies the more complex cvar interactions as much less null checking is required, and there's no need for one cvar's callback to call another's. nq-x11 is known to work at least well enough for the demos. More testing will come.
2022-04-23 03:22:45 +00:00
vulkan_use_validation ? ""
[vulkan] Fail gracefully if vulkan driver init fails Well, a little more gracefully than a segfault, at least.
2021-11-29 04:40:56 +00:00
: "\nSet vulkan_use_validation for details");
}
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
vulkan_ctx->choose_visual (vulkan_ctx);
vulkan_ctx->cmdpool = QFV_CreateCommandPool (vulkan_ctx->device,
vulkan_ctx->device->queue.queueFamily,
0, 1);
Sys_MaskPrintf (SYS_vulkan, "vk choose visual %p %p %d %#zx\n",
vulkan_ctx->device->dev, vulkan_ctx->device->queue.queue,
vulkan_ctx->device->queue.queueFamily,
(size_t) vulkan_ctx->cmdpool);
}
static void
[video] Get 16 and 32 bit sw32 mostly working in x11 Lighting on alias models seems to be borked, and skies are borked in both sw renderers (seems to be nothing to do with this commit, though).
2021-07-10 15:09:41 +00:00
vulkan_vid_render_create_context (void *data)
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
{
vulkan_ctx->create_window (vulkan_ctx);
vulkan_ctx->surface = vulkan_ctx->create_surface (vulkan_ctx);
[vulkan] Remove unused command buffer and fence
2022-05-31 02:05:12 +00:00
Sys_MaskPrintf (SYS_vulkan, "vk create context: surface:%#zx\n",
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
(size_t) vulkan_ctx->surface);
}
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
static vid_model_funcs_t model_funcs = {
[renderer] Use designated inits on more structs Finally, the model_funcs and render_funcs struts use designated initializers. Not only are they good for ensuring correct initialization, they're great for the programmer finding the right initializer.
2022-09-25 01:18:06 +00:00
.texture_render_size = sizeof (vulktex_t) + 2 * sizeof (qfv_tex_t),
.Mod_LoadLighting = vulkan_Mod_LoadLighting,
.Mod_SubdivideSurface = vulkan_Mod_SubdivideSurface,
.Mod_ProcessTexture = vulkan_Mod_ProcessTexture,
.Mod_LoadIQM = Mod_LoadIQM,
.Mod_LoadAliasModel = Mod_LoadAliasModel,
.Mod_LoadSpriteModel = Mod_LoadSpriteModel,
.Mod_MakeAliasModelDisplayLists = vulkan_Mod_MakeAliasModelDisplayLists,
.Mod_LoadAllSkins = vulkan_Mod_LoadAllSkins,
.Mod_FinalizeAliasModel = vulkan_Mod_FinalizeAliasModel,
.Mod_LoadExternalSkins = vulkan_Mod_LoadExternalSkins,
.Mod_IQMFinish = vulkan_Mod_IQMFinish,
.alias_cache = 0,
.Mod_SpriteLoadFrames = vulkan_Mod_SpriteLoadFrames,
.Skin_Free = Skin_Free,
.Skin_SetColormap = Skin_SetColormap,
.Skin_SetSkin = Skin_SetSkin,
.Skin_SetupSkin = vulkan_Skin_SetupSkin,
.Skin_SetTranslation = Skin_SetTranslation,
.Skin_ProcessTranslation = vulkan_Skin_ProcessTranslation,
.Skin_InitTranslations = vulkan_Skin_InitTranslations,
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
};
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
static void
vulkan_vid_render_init (void)
{
if (!vr_data.vid->vid_internal->vulkan_context) {
Sys_Error ("Sorry, Vulkan not supported by this program.");
}
vulkan_ctx = vr_data.vid->vid_internal->vulkan_context ();
vulkan_ctx->load_vulkan (vulkan_ctx);
Vulkan_Init_Common (vulkan_ctx);
[video] Get 16 and 32 bit sw32 mostly working in x11 Lighting on alias models seems to be borked, and skies are borked in both sw renderers (seems to be nothing to do with this commit, though).
2021-07-10 15:09:41 +00:00
vr_data.vid->vid_internal->data = vulkan_ctx;
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
vr_data.vid->vid_internal->set_palette = set_palette;
vr_data.vid->vid_internal->choose_visual = vulkan_vid_render_choose_visual;
vr_data.vid->vid_internal->create_context = vulkan_vid_render_create_context;
vr_funcs = &vulkan_vid_render_funcs;
m_funcs = &model_funcs;
}
static void
vulkan_vid_render_shutdown (void)
{
[vulkan] Fail gracefully if vulkan driver init fails Well, a little more gracefully than a segfault, at least.
2021-11-29 04:40:56 +00:00
if (!vulkan_ctx || !vulkan_ctx->device) {
return;
}
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
qfv_device_t *device = vulkan_ctx->device;
qfv_devfuncs_t *df = device->funcs;
VkDevice dev = device->dev;
QFV_DeviceWaitIdle (device);
[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
[vulkan] Get IQM rendering working The bones aren't animated yet (and I realized I made the mistake of thinking the bone buffer was per-model when it's really per-instance (I think this mistake is in the rest of QF, too)), skin rendering is a mess, need to default vertex attributes that aren't in the model... Still, it's quite satisfying seeing Mr Fixit on screen again :) I wound up moving the pipeline spec in with the rest of the pipelines as the system isn't really ready for separating them.
2022-05-07 01:08:46 +00:00
Mod_ClearAll ();
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
Vulkan_Compose_Shutdown (vulkan_ctx);
[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
Vulkan_Translucent_Shutdown (vulkan_ctx);
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
Vulkan_Lighting_Shutdown (vulkan_ctx);
Vulkan_Draw_Shutdown (vulkan_ctx);
[vulkan] Implement the sprite render passes It turned out the bindless approach wouldn't work too well for my design of the sprite objects, but I don't think that's a big issue at this stage (and it seems bindless is causing problems for brush/alias rendering via renderdoc and on my versa pro). However, I have figured out how to make effective use of descriptor sets (finally :P). The actual normal still needs checking, but the sprites are currently unlit so not an issue at this stage.
2021-12-14 16:22:05 +00:00
Vulkan_Sprite_Shutdown (vulkan_ctx);
[vulkan] Start work on particles for Vulkan This gets the pipelines loaded (and unloaded on shutdown). Probably the easy part :P. Still need to sort out the command buffers, synchronization, and particle generation (and probably a bunch else that's not coming to mind).
2021-12-16 14:17:01 +00:00
Vulkan_Particles_Shutdown (vulkan_ctx);
[vulkan] Get IQM rendering working The bones aren't animated yet (and I realized I made the mistake of thinking the bone buffer was per-model when it's really per-instance (I think this mistake is in the rest of QF, too)), skin rendering is a mess, need to default vertex attributes that aren't in the model... Still, it's quite satisfying seeing Mr Fixit on screen again :) I wound up moving the pipeline spec in with the rest of the pipelines as the system isn't really ready for separating them.
2022-05-07 01:08:46 +00:00
Vulkan_IQM_Shutdown (vulkan_ctx);
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
Vulkan_Bsp_Shutdown (vulkan_ctx);
Vulkan_Alias_Shutdown (vulkan_ctx);
[vulkan] Use a buffer for entity transform and color data This allows the use of an entity id to index into the entity data and fetch the transform and colormod data in the vertex shader, thus making instanced rendering possible. Non-world brush entities are still not rendered, but the world entity is using both the entity data buffer and entid buffer.
2022-05-24 15:17:57 +00:00
Vulkan_Scene_Shutdown (vulkan_ctx);
[vulkan] Move matrices into per-frame buffers This should fix the horrid frame rate dependent behavior of the view model. They are also in their own descriptor set so they can be easily shared between pipelines. This has been verified to work for Draw.
2021-12-08 06:28:21 +00:00
Vulkan_Matrix_Shutdown (vulkan_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
[vulkan] Adjust shutdown order slightly It makes more sense to shutdown the render passes before textures.
2022-11-22 04:30:29 +00:00
Vulkan_DestroyRenderPasses (vulkan_ctx);
[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
Vulkan_Output_Shutdown (vulkan_ctx);
[vulkan] Adjust shutdown order slightly It makes more sense to shutdown the render passes before textures.
2022-11-22 04:30:29 +00:00
[vulkan] Upload palette as a 16x16 image It turns out my approach to alias skin coloring just doesn't work for the quake data due to the color curves not having a linear relationship, especially the bottom colors.
2022-11-15 00:26:17 +00:00
Vulkan_Palette_Shutdown (vulkan_ctx);
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
Vulkan_Texture_Shutdown (vulkan_ctx);
[vulkan] Free the staging buffer's command buffers Since the staging buffer allocates the command buffers it uses, it needs to free them when it is freed. I think I was confused by the validation layers not complaining about unfreed buffers when shutting down, but that's because destroying the pool (during program shutdown, when the validation layers would complain) frees all the buffers. Thus, due to staging buffers being created and destroyed during the level load process, (rather large) command buffers were piling up like imps in a Doom level. In the process, it was necessary to rearrange some of the shutdown code because vulkan_vid_render_shutdown destroys the shared command pool, but the pool is required for freeing the command buffers, but there was a minor mess of long-lived staging buffers being freed afterwards. That didn't end particularly well.
2022-05-13 01:19:08 +00:00
QFV_DestroyStagingBuffer (vulkan_ctx->staging);
df->vkDestroyCommandPool (dev, vulkan_ctx->cmdpool, 0);
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
Vulkan_Shutdown_Common (vulkan_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
vid_render_funcs_t vulkan_vid_render_funcs = {
[renderer] Use designated inits on more structs Finally, the model_funcs and render_funcs struts use designated initializers. Not only are they good for ensuring correct initialization, they're great for the programmer finding the right initializer.
2022-09-25 01:18:06 +00:00
.init = vulkan_vid_render_init,
.Draw_CharBuffer = vulkan_Draw_CharBuffer,
[console] Resurrect console scaling Currently only for gl/glsl/vulkan. However, rather than futzing with con_width and con_height (and trying to guess good values), con_scale (currently an integer) gives consistent pixel scaling regardless of window size.
2022-11-13 13:23:56 +00:00
.Draw_SetScale = vulkan_Draw_SetScale,
[renderer] Use designated inits on more structs Finally, the model_funcs and render_funcs struts use designated initializers. Not only are they good for ensuring correct initialization, they're great for the programmer finding the right initializer.
2022-09-25 01:18:06 +00:00
.Draw_Character = vulkan_Draw_Character,
.Draw_String = vulkan_Draw_String,
.Draw_nString = vulkan_Draw_nString,
.Draw_AltString = vulkan_Draw_AltString,
.Draw_ConsoleBackground = vulkan_Draw_ConsoleBackground,
.Draw_Crosshair = vulkan_Draw_Crosshair,
.Draw_CrosshairAt = vulkan_Draw_CrosshairAt,
.Draw_TileClear = vulkan_Draw_TileClear,
.Draw_Fill = vulkan_Draw_Fill,
.Draw_Line = vulkan_Draw_Line,
.Draw_TextBox = vulkan_Draw_TextBox,
.Draw_FadeScreen = vulkan_Draw_FadeScreen,
.Draw_BlendScreen = vulkan_Draw_BlendScreen,
.Draw_CachePic = vulkan_Draw_CachePic,
.Draw_UncachePic = vulkan_Draw_UncachePic,
.Draw_MakePic = vulkan_Draw_MakePic,
.Draw_DestroyPic = vulkan_Draw_DestroyPic,
.Draw_PicFromWad = vulkan_Draw_PicFromWad,
.Draw_Pic = vulkan_Draw_Pic,
.Draw_Picf = vulkan_Draw_Picf,
.Draw_SubPic = vulkan_Draw_SubPic,
.Draw_AddFont = vulkan_Draw_AddFont,
.Draw_FontString = vulkan_Draw_FontString,
.ParticleSystem = vulkan_ParticleSystem,
.R_Init = vulkan_R_Init,
.R_ClearState = vulkan_R_ClearState,
.R_LoadSkys = vulkan_R_LoadSkys,
.R_NewScene = vulkan_R_NewScene,
.R_LineGraph = vulkan_R_LineGraph,
.begin_frame = vulkan_begin_frame,
.render_view = vulkan_render_view,
.draw_particles = vulkan_draw_particles,
.draw_transparent = vulkan_draw_transparent,
.post_process = vulkan_post_process,
.set_2d = vulkan_set_2d,
.end_frame = vulkan_end_frame,
.create_cube_map = vulkan_create_cube_map,
.create_frame_buffer = vulkan_create_frame_buffer,
.destroy_frame_buffer = vulkan_destroy_frame_buffer,
.bind_framebuffer = vulkan_bind_framebuffer,
.set_viewport = vulkan_set_viewport,
.set_fov = vulkan_set_fov,
.capture_screen = vulkan_capture_screen,
.model_funcs = &model_funcs
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
};
static general_funcs_t plugin_info_general_funcs = {
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
.shutdown = vulkan_vid_render_shutdown,
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
};
static general_data_t plugin_info_general_data;
static plugin_funcs_t plugin_info_funcs = {
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
.general = &plugin_info_general_funcs,
.vid_render = &vulkan_vid_render_funcs,
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
};
static plugin_data_t plugin_info_data = {
[util] Make PI_LoadPlugin always call general init function As the root cause for #16 was something else, this fixes only the basic cvar initialization, but does fix #19 (for now, at least).
2021-06-26 06:43:17 +00:00
.general = &plugin_info_general_data,
.vid_render = &vid_render_data,
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
};
static plugin_t plugin_info = {
Fix vid renderer plugin types I guess that plugin type is currently not checked, otherwise I doubt the mistake would have gone unnoticed.
2019-07-07 05:57:56 +00:00
qfp_vid_render,
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
0,
QFPLUGIN_VERSION,
"0.1",
Correct vulkan plugin strings
2019-07-07 05:59:20 +00:00
"Vulkan 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>\n"
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
"Please see the file \"AUTHORS\" for a list of contributors",
&plugin_info_funcs,
&plugin_info_data,
};
PLUGIN_INFO(vid_render, vulkan)
{
return &plugin_info;
}
Reference in a new issue Copy permalink