This is problematic as we don't have namespacing for these and some of
the macros can interfere with other defines.
This reverts commit 8634c7e349.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As weston_windowed_output_get_api needs ARRAY_LENGTH() move helpers to a
libweston/ so other users can re-use that instead of re-defining these
all over. Easier for other front-ends to make use of them.
With this change windowed-output-api.h also includes the helpers header.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Revert active unit to default value right after use so that other
functions can assume the default state. A best practices section is
added to the internal header for reference.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
The wireframe unit can only be used by the wireframe texture so
there's no need to bind it anymore before use.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Provide a fixed allocation to each texture unit in order to prevent
conflicts. This fixes a conflict between colour transforms and the
wireframe debug mode.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Don't color sub-mesh differently in wireframe mode. There's not much
interest in being able to distinguish the sub-meshes in a paint node
and this allows to simplify the logic by removing the color vertex
stream.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Current green tint support is a hard-coded Porter-Duff premultiplied
blending of a green source (slightly skewed on the green channel) over
the updated damaged destination. This commit makes green tinting
generic by letting the shader user provide a custom tint color.
The goal is to reuse that system for the upcoming debug modes.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Set up debug mode initial infrastructure using a dedicated key binding
and make shaders debug a debug mode.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Render wireframe within paint nodes instead of drawing lines in a
second pass. The wireframe is blended over the node in a single draw
call. This slightly simplifies the logic by removing the computation
of a second set of indices and enables wireframe anti-aliasing using
Celes and Abraham's "Fast and versatile texture-based wireframe
rendering" paper from 2011.
Celes and Abraham use a one-dimensional set of texture coords for each
triangle edge, 1.0 for the 2 vertices defining the edge and 0.0 for
the other vertex, which basically define barycentric coords. Texture
mapping and the mip chain is then exploited to give a constant-width
edge. The main drawback of the technique is that contour edges of
node's damage mesh are drawn half as thick as interior lines since
each triangle draws half of each line's thickness.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Seems like a typo, found by reading shader debug scope logs and
wondering why "!?!?" is there, e.g.:
Deleting shader program for: !?!? SHADER_VARIANT_XYUV
SHADER_COLOR_CURVE_IDENTITY SHADER_COLOR_MAPPING_IDENTITY
SHADER_COLOR_CURVE_IDENTITY -input_is_premult -green
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This makes the code slightly easier to read and prevents using
incorrect locations now that shader permutations can provide different
vertex streams.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Index vertices from the damage mesh as lines and emit a single draw
call in fan debug mode. A new shader path and an additional vertex
stream are added in order to filter the color of the solid shader
variant per sub-mesh.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Until now, all the curves would be represented with 3x1D LUT's. Now we
support LINPOW and POWLIN curves (arbitrary names that we've picked).
We can use these curves to represent LittleCMS curves type 1, 4 and
their inverses -1, -4. The reason why we want that is because we gain
precision using the parametric curves (compared to the LUT's);
Surprisingly we had to increase the tolerance of the sRGB->adobeRGB MAT
test. Our analysis is that the inverse EOTF power-law curve with
exponent 1.0 / 2.2 amplifies errors more than the LUT, specially for
input (optical) values closer to zero.
That makes sense, because this curve is more sensible to input values
closer to zero (i.e. little input variation results in lots of output
variation). And this model makes sense, as humans are more capable of
perceiving changes of light intensity in the dark.
But the downside of all that is that for input values closer to zero, a
little bit of noise increases significantly the error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the next commit we'll add support for more color curves. So move
lut_3x1d to an union.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Let the graphics hardware handle the transformation from surface
position to texture coordinates. Paint nodes now have a single vertex
position attribute from which texture coordinates are derived. A new
vertex shader variant handles the transformation.
Signed-off-by: Loïc Molinari <loic.molinari@gmail.com>
It should harmlessly fail or do nothing, but seeing attempts to set
uniform -1 can be confusing when looking for real shader issues.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Add matrix in color.h
Matrix is used as an optimized method for
color mapping vs 3DLUT.
Nothing sets color mapping to matrix yet.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Add post-curve support in color.h.
Pre-curve and post-curve describe color pipeline components
in a single GL shader invocation.The GL shader is supposed
to match struct weston_color_transform exactly.
We have the following color pipeline:
shader A -> blending -> shader B -> KMS. Both A and B shaders
using the same source file :fragment.glsl.
Each shader has pre and post curve.
The typical color pipeline with 3DLUT:
Shader A: pre-curve identity->3DLUT->blending->post-curve identity
Shader B: pre-curve->3DLUT identity->post-curve identity->KMS
The typical color pipeline with matrix (in next commits):
Shader A: pre-curve->matrix->blending->post-curve identity
Shader B: pre-curve->matrix identity->post-curve identity->KMS
The pre-curve plays role of EOTF (shader A) or INV_EOTF
(shader B) becouse we are stiching the shaders.
We assume that someone in the future may use both pre-curve
and post-curve, for example, when it is not possible to combine
these curves into 3DLUT and we will do mapping elements based on
their location in ICC profile.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
We always talk about "view alpha", so the name variable in the fragment
shader the same. Now it's clear without the comments, making the code
easier to read overall.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The following GL extensions provide support for shaders CM:
-GL_OES_texture_float_linear makes GL_RGB32F linear filterable.
-GL ES 3.0 provides Texture3D support in GL API.
-GL_OES_texture_3D provides sampler3D support in ESSL 1.00.
If abovesaid is supported then renderer sets flag WESTON_CAP_COLOR_OPS
which means that all fields in struct weston_color_transform are
supported, for example, 1DLUT and 3DLUT.
Use GL_OES_texture_3D to implement 3DLUT function which
uses trilinear interpolation for pixel processing or bypass as is.
Quote from https://nick-shaw.github.io/cinematiccolor/luts-and-transforms.html
"3D LUTs have long been embraced by color scientists and are one of
the tools commonly used for gamut mapping. In fact, 3D LUTs are used
within ICC profiles to model the complex device behaviors necessary
for accurate color image reproduction".
Quote from https://developer.nvidia.com/gpugems/gpugems2/part-iii-high-quality-rendering/
chapter-24-using-lookup-tables-accelerate-color
is about interpolation: "By generating intermediate results based
on a weighted average of the eight corners of the bounding cube,
this algorithm is typically sufficient for color processing,
and it is implemented in graphics hardware".
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
This adds shader support for using a three-channel one-dimensional
look-up table for de/encoding input colors. This operation will be useful
for applying EOTF or its inverse, in other words, gamma curves. It will
also be useful in optimizing a following 3D LUT tap distribution once
support for 3D LUT is added.
Even though called three-channel and one-dimensional, it is actually
implemented as a one-channel two-dimensional texture with four rows.
Each row corresponds to a source color channel except the fourth one is
unused. The reason for having the fourth row is to get texture
coordinates in 1/8 steps instead of 1/6 steps. 1/6 may would not be
exact in floating- or fixed-point arithmetic and might perhaps risk
unintended results from bilinear texture filtering when we want linear
filtering only in x but not in y texture coordinates. I may be paranoid.
The LUT is applied on source colors after they have been converted to
straight RGB. It cannot be applied with pre-multiplied alpha. A LUT can
be used for both applying EOTF to go from source color space to blending
color space, and EOTF^-1 to go from blending space to output
(electrical) space. However, this type of LUT cannot do color space
conversions.
For now, this feature is hardcoded to off everywhere, to be enabled in
following patches.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a new shader requirements bit input_is_premult which says whether
the texture sampling results in premultiplied alpha or not. Currently
this can be deduced fully from the shader texture variant, but in the
future there might a protocol extension to explicitly control it. Hence
the need for a new bit.
yuva2rgba() is changed to produce straight alpha always. This makes
sample_input_texture() sometimes produce straight or premultiplied
alpha. The input_is_premult bit needs to match sample_input_texture()
behavior. Doing this should save three multiplications in the shader for
straight alpha formats.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that pieces of color management implementation start to land, the
fallback shader becomes even more special than before. It is the only
case where the compositor ignores color management.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch gathers all values to be loaded to shader uniforms into a new
struct gl_shader_config along with texture target and filter
information. Struct gl_shader becomes opaque outside of gl-shaders.c.
Everything that used or open-coded these are converted.
The aim is to make gl-renderer.c easier to read. Previously, uniform
values were loaded up in various places, texture units were set up in
one place, textures were bound into units in different places. Stuff was
all over the place.
Now, shader requirements and associated uniform data is stored in a
single struct. The data is loaded into a shader program in one function
only.
That makes it easy for things like maybe_censor_override() to replace
the whole config rather than poke only the shader requirements. This may
not look like much right now, but when color management adds more
uniforms and even hardcoded color need to go through the proper color
pipeline, doing things the old way would become intractable.
Similar simplification can be seen in draw_view(), where the RGBA->RGBX
override becomes more contained. There is no longer a need to "pre-load"
the shader used by triangle fan debug. Triangle fan debug no longer
needs to play tricks with saving and restoring the current shader.
The real benefit of this change will probably come when almost all
shader operations need to take color spaces into account. That means
filling in gl_shader_config parts based on a color transformation.
This is based on an idea Sebastian already used in his Weston color
management work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These functions are related to shaders, so they are more at home in
gl-shaders.c. gl-renderer.c is too long already.
This allows making a couple functions static while the moved functions
become non-static. Future changes turn some of these functions into
static again, with the ultimate goal of making struct gl_shader opaque.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is useful for seeing that the shader program garbage collection
works in a future patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
One more thing is coming to need this, so add the compositor pointer and
migrate existing places to use it where it simplifies things.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A more unique name is easier to grep for. Using 'color' as a local
variable might be useful in the future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This helps accounting how many shaders live in the cache, what the
shader source code is, and when shaders are compiled.
Signed-off-by: Harish Krupo <harishkrupo@gmail.com>
v2: Resolved rebase conflicts.
Put shader_scope in struct gl_renderer, remove struct
gl_shader_generator.
Wrote commit message.
Rebased for "gl-renderer: rewrite fragment shaders" which completely
changed how shader sources are generated.
Added cache statistics to debug output on subscribe.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch modifies the shader generation code so that the shaders are
stitched together based on the requirement instead of creating them
during initialization. This is necessary for HDR use cases where each
surface would have different properties based on which different
de-gamma or tone mapping or gamma shaders are stitched together.
v2: Use /* */ instead of // (Pekka)
Move shader strings to gl-shaders.c file (Pekka)
Remove Makefile.am changes (Pekka)
Use a struct instead of uint32_t for storing requirements (Pekka)
Clean up shader list on destroy (Pekka)
Rename shader_release -> shader_destroy (Pekka)
Move shader creation/deletion into gl-shaders.c (Pekka)
Use create_shaders's multi string capbility instead of
concatenating (Pekka)
v3: Add length check when adding shader string (Pekka)
Signed-off-by: Harish Krupo <harishkrupo@gmail.com>
v4: Rebased, PROTECTION_MODE_ENFORCED converted.
Dropped unnecessary { }.
Ported setup_censor_overrides().
Split out moving code into gl-shaders.c.
Changed to follow "gl-renderer: rewrite fragment shaders",
no more shader source stitching.
Added SHADER_VARIANT_XYUV.
Const'fy function arguments.
Added gl_shader_requirements_cmp() and moved the early return in
use_gl_program().
Moved use_gl_program() before first use in file.
Split solid shader requirements by use case: requirements_censor and
requirements_triangle_fan.
Simplified fragment_debug_binding() since no need to force anything.
Ensure struct gl_shader_requirements has no padding. This allows us
to use normal C syntax instead of memset() and memcpy() when
initializing or assigning. See also:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2071
Make it also a bitfield to squeeze the size.
v5: Move wl_list_insert() into gl_shader_create() (Daniel)
Compare variant to explicit value. (Daniel)
Change functions to gl_renderer_get_program,
gl_renderer_use_program, and
gl_renderer_use_program_with_view_uniforms.
Use local variable instead of gr->current_shader. (Daniel)
Simplified gl_renderer_get_program.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
To help debugging shader compilation errors, print the shader source the
way it was given to the GLSL compiler and with line numbers that match
the compiler error messages.
This is necessary because some snippets are added at runtime to the
beginning, the source is not only what is in the respective .glsl file.
I did look into using #line directives, but you cannot put source file
names to it, only "source string numbers" which must be an integer
expression. If we used #line, the reader would need to know that string
number 0 is the version, string 1 is the config and string number 2 is
fragment.glsl. I think that would have been too cumbersome.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The main goal of this patch is to improve the readability of how and
what fragment shaders are generated.
Instead of having C code that assembles each shader variant from literal
string snippets, create one big fragment shader source that has
everything in it. This relies on a GLSL compiler to optimize statically
false conditions and unused uniforms away.
Having all the fragment shader code in one file, uncluttered by C string
literal syntax, improves readability significantly. A disadvantage is
that the code is more verbose, but it allows comments much better.
The actual shader code is kept unchanged except:
- FRAGMENT_CONVERT_YUV macro is now a proper function
- GLSL version is explicitly set to 1.00 ES
- RGBA and EXTERNAL use the same path, the difference is how the sampler
is declared
Further shader code consolidation is possible, but is left for another
time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch adds the tooling for incorporating files as C data, so that
files can be built into the binaries. The tool is in Python to avoid
adding extra dependencies like xxd.
xxd.py is copied from Mesa as-is, from commit
b729cd58d76f97f3fc04a67569535ee5ef2f5278 (master branch on 2021-01-26),
a.k.a 21.0-branchpoint-635-gb729cd58d76.
Moving the GLSL vertex shader into a separate file is not that
interesting, the purpose of this commit is to provide a simple
demonstration of the tooling. The real benefits come in a following
patch where the fragment shaders are re-written and externalized.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is purely moving code as is with no changes other than making the
three functions non-static.
Originally this was part of "gl-renderer: Requirement based shader
generation" by Harish Krupo, but that patch made also big changes to the
code at the same time. Patches are easier to review when code movement
is separate from behavioral changes, therefore I introduced this patch.
Cc: Harish Krupo <harishkrupo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
