The channel ordering system currently proposes to swizzle components
in the fragment shader for a few combinations. This commit replaces
this system with texture swizzling parameters in order to support all
the possible combinations in a more efficient way.
This will allow to easily add a lot more formats and as a nice side
effect to force components to 0 or 1, which is useful for opaque
formats.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
OpenGL ES 3 adds support for texture swizzling parameters in order to
let graphics drivers efficiently swizzle R, G, B and A components at
texture look-up, with the nice feature of allowing 0 and 1 as
supported values.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Cache and update texture parameters only when changed by storing
minification/magnification filters, wrap modes and their target into a
dedicated gl_texture_parameters structure and by calling new utility
functions to create and flush parameters.
This structure is itself stored into the buffer state for each texture
of a surface and into the output state for border and shadow textures.
The shader config filled before emitting a draw call now just takes a
pointer to the array of texture ids, a pointer to the array of
parameters and the number of textures.
This allows to simplify the logic in gl-renderer.c, to minimise GL
state changes and to let the utility wrapper validate the parameters.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
EXT_EGL_image_storage provides a mechanism for creating texture
objects that are both EGL image targets and immutable. When available,
this makes the texture object target immutable, preventing
respecifications.
While adding support for that extension, it appeared that the
compositor calls attach_buffer() at every buffer updates and that the
texture object is each time respecified to the same EGL image. This
commit additionally prevents any respecification when
EXT_EGL_image_storage isn't available.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
A new gl_format_info structure is added to the pixel_format_info
structure in order to store new GL format information (compatible with
Table 1 in gl-utils.c) for each supported format. There will be a
temporary duplication of GL format info in order to keep other parts
of the code not yet ported working. That will be removed later.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
EXT_texture_format_BGRA8888 allows OpenGL ES implementations to
support GL_BGRA8_EXT FBO and texture format.
OpenGL implementations handle the spec differently regarding the use
of GL_BGRA8_EXT or GL_BGRA_EXT with TexStorage*D(), TexImage*D() and
RenderbufferStorage(). A recent revision of the spec (and Mesa)
clarifies all that, but in order to support most drivers we simply
check which method is supported by order of preference.
Co-authored-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Before the creation of the EXT_texture_storage extension,
OES_required_internalformat used to guarantee minimal FBO and texture
precisions to OpenGL ES 1 and 2 implementations using sized internal
formats.
Note that new external format and type combinations (like for instance
GL_RGB and GL_UNSIGNED_BYTE for the GL_RGB565 sized internal format)
should be available when OES_required_internalformat is supported.
This isn't supported by this wrapper for now because of the implicit
conversion in gl_texture_2d_init() that forces a specific type when
EXT_texture_storage isn't available.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
QCOM_render_sRGB_R8_RG8 allows OpenGL ES 3 implementations to support
GL_SR8_EXT and GL_SRG8_EXT FBO formats.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
EXT_texture_sRGB_RG8 allows OpenGL ES 3 implementations to support
GL_SRG8_EXT texture format.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
EXT_texture_sRGB_R8 allows OpenGL ES 3 implementations to support
GL_SR8_EXT texture format.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
APPLE_texture_packed_float allows OpenGL ES 2 implementations to
support GL_R11F_G11F_B10F and GL_RGB9_A5 texture formats.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
NV_packed_float allows OpenGL ES 2 implementations to support
GL_R11F_G11F_B10F FBO and texture format.
Note that GL_HALF_FLOAT should be available (the spec is a bit
confusing) as type combination with the GL_RGB external format when
both NV_packed_float and OES_texture_half_float are supported on
OpenGL ES 2. This isn't supported by this wrapper for now because of
the implicit conversion in gl_texture_2d_init() that forces a specific
type when EXT_texture_storage isn't available.
NV_packed_float_linear would require a new utility function to
retrieve whether a texture can be linearly interpolated by the texture
samplers or not. This hasn't been added for the other formats because
there's no users for now but this might be added later.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
EXT_color_buffer_float allows OpenGL ES implementations to support
GL_R16F, GL_RG16F, GL_RGBA16F, GL_R32F, GL_RG32F, GL_RGBA32F and
GL_R11F_G11F_B10F FBO formats. All of these are supported by default
from OpenGL ES 3.2.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
OES_texture_float allows OpenGL ES 2 implementations to support
GL_R32F, GL_RG32F, GL_RGB32F and GL_RGBA32F texture formats.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
OES_texture_half_float allows OpenGL ES 2 implementations to support
GL_R16F, GL_RG16F, GL_RGB16F and GL_RGBA16F texture formats.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
OpenGL ES 2 implementations support texture immutability and sized
internal formats using the GL_EXT_texture_storage extension.
Co-authored-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Validate the colour-renderable sized internal formats passed to
gl_fbo_init() using a new gl_fbo_is_format_supported() utility. Sized
internal formats are now required. More formats will progressively be
added depending on the OpenGL ES version and the supported extensions.
Support for RGBA8 FBOs is now required by the GL renderer.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Avoid duplicating the inclusion of the GLES headers by including them
once in gl-renderer-internal.h.
Upgrade GLES3 header to gl32.h.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
These utility functions are used (or will be used) in different source
files. This prevents gl-renderer.c from growing too much (the coming
texture utilities are quite verbose) by moving generic functions out.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
As most SDR video content uses that instead of BT.601. Crucially, most
KMS drivers use BT.709 as the default for the COLOR_ENCODING value,
making it the effective default for hardware planes we used before we
started setting an explicit value.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
In order to be consistent with our internal YUV shader and KMS plane
output. Note that the extension requires the hints to be ignored for
RGB formats.
Note that the attribs array previously was slightly larger than the
maximum number of attributes required.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
When we use perfetto, we'll want to enable the renderer timepoints, which
are currently gated behind weston_log_scope_is_enabled(). So let's make a
function that checks if either the timeline scope or perfetto is enabled.
We do not yet process these timepoints, that comes in a future commit.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
I'll be adding perfetto instrumentation, which will want to know the
timepoint name without having to parse it.
For now, just pass an enum and add a helper function to convert to strings.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Add asserts ensuring that outputs aren't created or destroyed twice
and that a valid pair of output/renderbuffer is passed to
repaint_output().
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Accumulate renderbuffer damages and select a GL renderbuffer for
repaint in a dedicated function.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Coalesce gl_renderer_create_renderbuffer_window() and
output_get_window_renderbuffer() into a single
gl_renderer_get_renderbuffer_window() function.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Use the term window instead of dummy to make it clear we're dealing
with buffers allocated by the window-system.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Although backends can create renderbuffers of any size, they always
request the output's current mode size (including decorations).
Letting backends ask for a different size than the output has a few
read-back related design issues like for instance weston_renderer's
read_pixels() API users, currently assuming the output size and
without knowledge of renderbuffers, can retrieve cropped images if a
backend asks for a smaller size. Same issue for the output capture
subsystem.
This commit proposes to fix these issues by simply, albeit perhaps
radically, removing the width and height parameters from
create_renderbuffer(), enforcing the current mode's size of the
associated output.
The VNC and PipeWire backends now also access the output size via the
current mode, not through the width and height variables. This has the
benefit of unifying the backends, as well as the renderers, in their
use of output sizes.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
The Pixman renderer creates renderbuffers with the create_image() and
create_image_from_ptr() functions. The recent addition of the GL
renderer's create_fbo() function, which is pretty similar to the
Pixman ones, brings the opportunity to unify Pixman and GL renderers.
This commit proposes a common renderer function create_renderbuffer()
to create a renderbuffer of the specified format with an optional user
provided destination buffer.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This avoids having to re-bind them in functions that reuse them
immediately afterwards and does not affect any other parts of code.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This commit makes gl_fbo_texture_init() and gl_fbo_texture_fini()
consistent with the new FBO handling utilities by using the same
conventions: output parameters, variable names, descriptions.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Remove the glGetError() check from gl_fbo_image_init() after the call
to glEGLImageTargetRenderbufferStorageOES(). It would probably just
return a previous error queued by an unrelated GL call because the
error flags aren't cleared. So instead of obfuscating the code, this
commit removes that check and relies instead on the framebuffer
completeness check which will better report issues.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Add generic gl_fbo_init(), gl_fbo_image_init() and gl_fbo_fini()
utilities to the GL renderer and make use of these in the renderbuffer
creation functions.
This also fixes a framebuffer object leak on dma-buf renderbuffer
creation when the EGLImageTargetRenderbufferStorageOES() call fails.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
There's no need to render the surface content to a GL texture so make
it render to a GL renderbuffer instead.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Move gl_renderer_create_renderuffer_dmabuf() along with the other
renderbuffer creation functions, using a common naming pattern.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This makes type specific accesses more explicit and less verbose than
the container_of/base alternative which was needed when the base
renderbuffer type was exposed in libweston-internal.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
No backends currently create FBO or dma-buf renderbuffers on outputs
associated to a window. This is theoretically possible though and
should be allowed by the GL renderer. This commit prevents
output_get_dummy_renderbuffer() from mixing up renderbuffer types.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Stale renderbuffers are kept in the renderbuffer list until they're
destroyed by the backend. In the meantime, they shouldn't accumulate
damages since they won't be used anymore.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
It's currently assumed by backends that renderers discard
renderbuffers on resize. This commit introduces a new
weston_renderbuffer_discarded_func callback that must be passed at
renderbuffer creation in order to be notified of discarded events from
the renderer. This discarded event could potentially be reused later
by renderers on other occasions without having to change backends once
they get proper support for that.
On output resize, once a discarded event handler fails (returns false)
on a renderbuffer, all the remaining renderbuffers in the output list
go stale and weston_renderer_resize_output() ultimately returns false
for backends to be notified of the failure.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Renderbuffers currently have a libweston-internal base data structure
with a ref-counting system to handle their lifetime. The problem is
that renderers keep a ref to all renderbuffers in a list per output
(to deal with damages) and that it prevents backends from releasing
renderbuffer resources when not needed anymore. Renderbuffers are then
only released (last ref removed) when the output is destroyed or
resized. dma-buf renderbuffers even expose a dedicated function
remove_renderbuffer_dmabuf() to explictly request the release of their
resources.
This commit proposes to get rid of the ref-counting system by exposing
a single entry point to explicitly destroy all types of renderbuffers
from the renderer.
Instead of removing a renderbuffer from its output list and dropping
its ref when the output is resized, this commit also introduces the
concept of stale renderbuffers which consists in releasing the
resources of a renderbuffer when it's discarded by the renderer while
keeping it in the output list, with a stale state, until it's
explicitly destroyed.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Move the responsibility for damaging the entire area of new
renderbuffers from backends to renderers.
There's one little drawback: VNC damage logging can't log the
accumulated renderbuffer damage anymore, but I guess this should
somehow be done as an option in the renderers.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
