AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-11-14 20:51:07 +00:00
Code Issues Projects Releases Wiki Activity
23081d2bc4
gtk/gsk/gpu/gskglbuffer.c

209 lines
4.3 KiB
C
Raw Normal View History

gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
#include "config.h"
#include "gskglbufferprivate.h"
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
/* {{{ GskGLBuffer */
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
struct _GskGLBuffer
{
GskGpuBuffer parent_instance;
GLenum target;
GLuint buffer_id;
gpu: Don't try to be smart Don't try to use all those fancy GL features like glMapBuffer() and such. Just malloc() some buffer memory and glBufferSubData() it later. That works everywhere and is faster than (almost?) any combination of fancy new buffer APIs. And yes I'm frustrated because I played with those flags and none of them were better than this. Doubles the framerate on my discrete AMD GPU.
2023-10-04 19:42:36 +00:00
guchar *data;
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
};
G_DEFINE_TYPE (GskGLBuffer, gsk_gl_buffer, GSK_TYPE_GPU_BUFFER)
static void
gsk_gl_buffer_finalize (GObject *object)
{
GskGLBuffer *self = GSK_GL_BUFFER (object);
glDeleteBuffers (1, &self->buffer_id);
G_OBJECT_CLASS (gsk_gl_buffer_parent_class)->finalize (object);
}
static guchar *
gsk_gl_buffer_map (GskGpuBuffer *buffer)
{
GskGLBuffer *self = GSK_GL_BUFFER (buffer);
gpu: Don't try to be smart Don't try to use all those fancy GL features like glMapBuffer() and such. Just malloc() some buffer memory and glBufferSubData() it later. That works everywhere and is faster than (almost?) any combination of fancy new buffer APIs. And yes I'm frustrated because I played with those flags and none of them were better than this. Doubles the framerate on my discrete AMD GPU.
2023-10-04 19:42:36 +00:00
return self->data;
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
}
static void
gsk/gpu: avoid unnecessary buffer uploads Some maps are used for read only and do not require uploading contents back to the GPU afterwards. In other cases, we can often upload less than the fully allocated buffer size.
2024-03-08 21:54:53 +00:00
gsk_gl_buffer_unmap (GskGpuBuffer *buffer,
gsize used)
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
{
}
static void
gsk_gl_buffer_class_init (GskGLBufferClass *klass)
{
GskGpuBufferClass *buffer_class = GSK_GPU_BUFFER_CLASS (klass);
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
buffer_class->map = gsk_gl_buffer_map;
buffer_class->unmap = gsk_gl_buffer_unmap;
gobject_class->finalize = gsk_gl_buffer_finalize;
}
static void
gsk_gl_buffer_init (GskGLBuffer *self)
{
}
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
void
gsk_gl_buffer_bind (GskGLBuffer *self)
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
{
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
glBindBuffer (self->target, self->buffer_id);
}
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
void
gsk_gl_buffer_bind_base (GskGLBuffer *self,
GLuint index)
{
glBindBufferBase (self->target, index, self->buffer_id);
}
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
static void
gsk_gl_buffer_setup (GskGLBuffer *self,
GLenum target,
gsize size)
{
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
gsk_gpu_buffer_setup (GSK_GPU_BUFFER (self), size);
self->target = target;
glGenBuffers (1, &self->buffer_id);
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
}
/* }}} */
/* {{{ GskGLMappedBuffer */
struct _GskGLMappedBuffer
{
GskGLBuffer parent_instance;
};
G_DEFINE_TYPE (GskGLMappedBuffer, gsk_gl_mapped_buffer, GSK_TYPE_GL_BUFFER)
static void
gsk_gl_mapped_buffer_finalize (GObject *object)
{
GskGLBuffer *self = GSK_GL_BUFFER (object);
gsk_gl_buffer_bind (self);
glUnmapBuffer (self->target);
G_OBJECT_CLASS (gsk_gl_mapped_buffer_parent_class)->finalize (object);
}
static void
gsk_gl_mapped_buffer_class_init (GskGLMappedBufferClass *klass)
{
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
gobject_class->finalize = gsk_gl_mapped_buffer_finalize;
}
static void
gsk_gl_mapped_buffer_init (GskGLMappedBuffer *self)
{
}
GskGpuBuffer *
gsk_gl_mapped_buffer_new (GLenum target,
gsize size)
{
GskGLBuffer *self;
self = g_object_new (GSK_TYPE_GL_MAPPED_BUFFER, NULL);
gsk_gl_buffer_setup (self, target, size);
gsk_gl_buffer_bind (self);
glBufferStorage (target,
size,
NULL,
GL_MAP_READ_BIT | GL_MAP_WRITE_BIT | GL_MAP_PERSISTENT_BIT | GL_MAP_COHERENT_BIT);
self->data = glMapBufferRange (target,
0,
size,
GL_MAP_READ_BIT | GL_MAP_WRITE_BIT | GL_MAP_PERSISTENT_BIT | GL_MAP_COHERENT_BIT);
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
return GSK_GPU_BUFFER (self);
}
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
/* }}} */
/* {{{ GskGLCopiedBuffer */
struct _GskGLCopiedBuffer
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
{
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
GskGLBuffer parent_instance;
};
G_DEFINE_TYPE (GskGLCopiedBuffer, gsk_gl_copied_buffer, GSK_TYPE_GL_BUFFER)
static void
gsk_gl_copied_buffer_finalize (GObject *object)
{
GskGLBuffer *self = GSK_GL_BUFFER (object);
g_free (self->data);
G_OBJECT_CLASS (gsk_gl_copied_buffer_parent_class)->finalize (object);
gpu: Add ability to run shaders This heaves over an inital chunk of code from the Vulkan renderer to execute shaders. The only shader that exists for now is a shader that draws a single texture. We use that to replace the blit op we were doing before.
2023-08-21 00:18:37 +00:00
}
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
static void
gsk_gl_copied_buffer_unmap (GskGpuBuffer *buffer,
gsize used)
gpu: Add float array to shaders and add an ubershader ... and use it for a naive color node implementation using both so I can test it actually works.
2023-08-30 19:57:41 +00:00
{
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
GskGLBuffer *self = GSK_GL_BUFFER (buffer);
if (used == 0)
return;
gsk_gl_buffer_bind (self);
glBufferSubData (self->target, 0, used, self->data);
}
static void
gsk_gl_copied_buffer_class_init (GskGLCopiedBufferClass *klass)
{
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
GskGpuBufferClass *buffer_class = GSK_GPU_BUFFER_CLASS (klass);
gobject_class->finalize = gsk_gl_copied_buffer_finalize;
buffer_class->unmap = gsk_gl_copied_buffer_unmap;
}
static void
gsk_gl_copied_buffer_init (GskGLCopiedBuffer *self)
{
}
GskGpuBuffer *
gsk_gl_copied_buffer_new (GLenum target,
gsize size)
{
GskGLBuffer *self;
self = g_object_new (GSK_TYPE_GL_COPIED_BUFFER, NULL);
gsk_gl_buffer_setup (self, target, size);
gsk_gl_buffer_bind (self);
glBufferData (target, size, NULL, GL_STATIC_DRAW);
self->data = malloc (size);
return GSK_GPU_BUFFER (self);
gpu: Add float array to shaders and add an ubershader ... and use it for a naive color node implementation using both so I can test it actually works.
2023-08-30 19:57:41 +00:00
}
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
/* }}} */
Reference in New Issue Copy Permalink