AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
6efe31e6f5
gtk2/gsk/ngl/gsknglprogram.c

177 lines
5.1 KiB
C
Raw Normal View History

gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
/* gsknglprogram.c
*
* Copyright 2020 Christian Hergert <chergert@redhat.com>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library 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
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this program. If not, see <http://www.gnu.org/licenses/>.
*
* SPDX-License-Identifier: LGPL-2.1-or-later
*/
#include "config.h"
#include "gsknglcommandqueueprivate.h"
#include "gsknglprogramprivate.h"
#include "gskngluniformstateprivate.h"
G_DEFINE_TYPE (GskNglProgram, gsk_ngl_program, G_TYPE_OBJECT)
GskNglProgram *
gsk_ngl_program_new (GskNglDriver *driver,
const char *name,
int program_id)
{
GskNglProgram *self;
g_return_val_if_fail (GSK_IS_NGL_DRIVER (driver), NULL);
g_return_val_if_fail (program_id >= -1, NULL);
self = g_object_new (GSK_TYPE_GL_PROGRAM, NULL);
self->id = program_id;
self->name = g_strdup (name);
self->driver = g_object_ref (driver);
ngl: move uniform key mapping into uniform state Previously, we translated the uniform key (an enum) into a location within the shader program in GskNglProgram. A number of performance improvements were focused around having low nubers for the uniform locations. Generally this is the case, but some drivers such as old Intel drivers on Windows may use rather large numbers for those. To combat this, we can push the translation of uniform keys into locations at the GskNglUniformState level so that we work with unranslated keys through the process until applying them. Fixes #3780
2021-03-23 19:10:12 +00:00
self->n_mappings = 0;
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
return self;
}
static void
gsk_ngl_program_finalize (GObject *object)
{
GskNglProgram *self = (GskNglProgram *)object;
if (self->id >= 0)
g_warning ("Leaking GLSL program %d (%s)",
self->id,
self->name ? self->name : "");
g_clear_pointer (&self->name, g_free);
g_clear_object (&self->driver);
G_OBJECT_CLASS (gsk_ngl_program_parent_class)->finalize (object);
}
static void
gsk_ngl_program_class_init (GskNglProgramClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->finalize = gsk_ngl_program_finalize;
}
static void
gsk_ngl_program_init (GskNglProgram *self)
{
self->id = -1;
ngl: move uniform key mapping into uniform state Previously, we translated the uniform key (an enum) into a location within the shader program in GskNglProgram. A number of performance improvements were focused around having low nubers for the uniform locations. Generally this is the case, but some drivers such as old Intel drivers on Windows may use rather large numbers for those. To combat this, we can push the translation of uniform keys into locations at the GskNglUniformState level so that we work with unranslated keys through the process until applying them. Fixes #3780
2021-03-23 19:10:12 +00:00
for (guint i = 0; i < G_N_ELEMENTS (self->mappings); i++)
self->mappings[i].location = -1;
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
}
/**
* gsk_ngl_program_add_uniform:
gsk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 03:40:54 +00:00
* @self: a `GskNglProgram`
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
* @name: the name of the uniform such as "u_source"
* @key: the identifier to use for the uniform
*
* This method will create a mapping between @key and the location
* of the uniform on the GPU. This simplifies calling code to not
* need to know where the uniform location is and only register it
* when creating the program.
*
* You might use this with an enum of all your uniforms for the
* program and then register each of them like:
*
* ```
* gsk_ngl_program_add_uniform (program, "u_source", UNIFORM_SOURCE);
* ```
*
* That allows you to set values for the program with something
* like the following:
*
* ```
* gsk_ngl_program_set_uniform1i (program, UNIFORM_SOURCE, 1);
* ```
*
* Returns: %TRUE if the uniform was found; otherwise %FALSE
*/
gboolean
gsk_ngl_program_add_uniform (GskNglProgram *self,
const char *name,
guint key)
{
GLint location;
g_return_val_if_fail (GSK_IS_NGL_PROGRAM (self), FALSE);
g_return_val_if_fail (name != NULL, FALSE);
ngl: move uniform key mapping into uniform state Previously, we translated the uniform key (an enum) into a location within the shader program in GskNglProgram. A number of performance improvements were focused around having low nubers for the uniform locations. Generally this is the case, but some drivers such as old Intel drivers on Windows may use rather large numbers for those. To combat this, we can push the translation of uniform keys into locations at the GskNglUniformState level so that we work with unranslated keys through the process until applying them. Fixes #3780
2021-03-23 19:10:12 +00:00
g_return_val_if_fail (key < G_N_ELEMENTS (self->mappings), FALSE);
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
ngl: move uniform key mapping into uniform state Previously, we translated the uniform key (an enum) into a location within the shader program in GskNglProgram. A number of performance improvements were focused around having low nubers for the uniform locations. Generally this is the case, but some drivers such as old Intel drivers on Windows may use rather large numbers for those. To combat this, we can push the translation of uniform keys into locations at the GskNglUniformState level so that we work with unranslated keys through the process until applying them. Fixes #3780
2021-03-23 19:10:12 +00:00
location = glGetUniformLocation (self->id, name);
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
ngl: move uniform key mapping into uniform state Previously, we translated the uniform key (an enum) into a location within the shader program in GskNglProgram. A number of performance improvements were focused around having low nubers for the uniform locations. Generally this is the case, but some drivers such as old Intel drivers on Windows may use rather large numbers for those. To combat this, we can push the translation of uniform keys into locations at the GskNglUniformState level so that we work with unranslated keys through the process until applying them. Fixes #3780
2021-03-23 19:10:12 +00:00
/* Register the information even if unused */
self->mappings[key].name = g_intern_string (name);
self->mappings[key].location = location;
if (key >= self->n_mappings)
self->n_mappings = key + 1;
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
#if 0
ngl: move uniform key mapping into uniform state Previously, we translated the uniform key (an enum) into a location within the shader program in GskNglProgram. A number of performance improvements were focused around having low nubers for the uniform locations. Generally this is the case, but some drivers such as old Intel drivers on Windows may use rather large numbers for those. To combat this, we can push the translation of uniform keys into locations at the GskNglUniformState level so that we work with unranslated keys through the process until applying them. Fixes #3780
2021-03-23 19:10:12 +00:00
g_print ("program [%d] %s uniform %s [%u of %u] at location %d.\n",
self->id, self->name, name, key, self->n_mappings, location);
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
#endif
ngl: move uniform key mapping into uniform state Previously, we translated the uniform key (an enum) into a location within the shader program in GskNglProgram. A number of performance improvements were focused around having low nubers for the uniform locations. Generally this is the case, but some drivers such as old Intel drivers on Windows may use rather large numbers for those. To combat this, we can push the translation of uniform keys into locations at the GskNglUniformState level so that we work with unranslated keys through the process until applying them. Fixes #3780
2021-03-23 19:10:12 +00:00
return location > -1;
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
}
/**
* gsk_ngl_program_delete:
gsk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 03:40:54 +00:00
* @self: a `GskNglProgram`
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
*
* Deletes the GLSL program.
*
* You must call gsk_ngl_program_use() before and
* gsk_ngl_program_unuse() after this function.
*/
void
gsk_ngl_program_delete (GskNglProgram *self)
{
g_return_if_fail (GSK_IS_NGL_PROGRAM (self));
g_return_if_fail (self->driver->command_queue != NULL);
gsk_ngl_command_queue_delete_program (self->driver->command_queue, self->id);
self->id = -1;
}
/**
* gsk_ngl_program_uniforms_added:
gsk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 03:40:54 +00:00
* @self: a `GskNglProgram`
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
* @has_attachments: if any uniform is for a bind/texture attachment
*
* This function should be called after all of the uniforms ahve
* been added with gsk_ngl_program_add_uniform().
*
* This function will setup the uniform state so that the program
* has fast access to the data buffers without as many lookups at
* runtime for comparison data.
*/
void
gsk_ngl_program_uniforms_added (GskNglProgram *self,
gboolean has_attachments)
{
g_return_if_fail (GSK_IS_NGL_PROGRAM (self));
g_return_if_fail (self->uniforms == NULL);
self->uniforms = self->driver->command_queue->uniforms;
ngl: move uniform key mapping into uniform state Previously, we translated the uniform key (an enum) into a location within the shader program in GskNglProgram. A number of performance improvements were focused around having low nubers for the uniform locations. Generally this is the case, but some drivers such as old Intel drivers on Windows may use rather large numbers for those. To combat this, we can push the translation of uniform keys into locations at the GskNglUniformState level so that we work with unranslated keys through the process until applying them. Fixes #3780
2021-03-23 19:10:12 +00:00
self->program_info = gsk_ngl_uniform_state_get_program (self->uniforms, self->id, self->mappings, self->n_mappings);
gsk: add OpenGL based GskNglRenderer The primary goal here was to cleanup the current GL renderer to make maintenance easier going forward. Furthermore, it tracks state to allow us to implement more advanced renderer features going forward. Reordering This renderer will reorder batches by render target to reduce the number of times render targets are changed. In the future, we could also reorder by program within the render target if we can determine that vertices do not overlap. Uniform Snapshots To allow for reordering of batches all uniforms need to be tracked for the programs. This allows us to create the full uniform state when the batch has been moved into a new position. Some care was taken as it can be performance sensitive. Attachment Snapshots Similar to uniform snapshots, we need to know all of the texture attachments so that we can rebind them when necessary. Render Jobs To help isolate the process of creating GL commands from the renderer abstraction a render job abstraction was added. This could be extended in the future if we decided to do tiling. Command Queue Render jobs create batches using the command queue. The command queue will snapshot uniform and attachment state so that it can reorder batches right before executing them. Currently, the only reordering done is to ensure that we only visit each render target once. We could extend this by tracking vertices, attachments, and others. This code currently uses an inline array helper to reduce overhead from GArray which was showing up on profiles. It could be changed to use GdkArray without too much work, but had roughly double the instructions. Cycle counts have not yet been determined. GLSL Programs This was simplified to use XMACROS so that we can just extend one file (gskglprograms.defs) instead of multiple places. The programs are added as fields in the driver for easy access. Driver The driver manages textures, render targets, access to atlases, programs, and more. There is one driver per display, by using the shared GL context. Some work could be done here to batch uploads so that we make fewer calls to upload when sending icon theme data to the GPU. We'd need to keep a copy of the atlas data for such purposes.
2020-12-19 01:36:59 +00:00
self->program_info->has_attachments = has_attachments;
}
Reference in New Issue Copy Permalink