> On July 12, 2016, 8:07 a.m., Martin Gräßlin wrote:
> > What about shader variants for GLES? There are also two versions, one being
> > like the old one and one like core. In KWin we can handle this with the
> > same shader code and rewriting e.g. the version statement. Do you know how
> > this is handled in QtQuick?
>
> David Edmundson wrote:
> As I understand it GLES is a subset of GL, so as long as you just stick
> to using only subset in the first place you don't need two.
>
> I tried to mimc what Qt does exactly. They seem to just have the two:
> "normal" and ">3.2 Core" both completely from scratch.
> Poke me on IRC and I'll point you to the code locations.
>
> The only difference is they have the shaders as embedded Qt resources
> file and load them by name.
GLES being a subset of GL - keep on dreaming ;-) GLES is both a subset and a
superset of GL. And the shading language has quite some differences, especially
different version numbers.
KWin's generation code is:
} else {
const bool glsl_es_300 = GLPlatform::instance()->glslVersion() >=
kVersionNumber(3, 0);
if (glsl_es_300)
stream << "#version 300 es\n\n";
// From the GLSL ES specification:
//
// "The fragment language has no default precision qualifier for
floating point types."
stream << "precision highp float;\n\n";
varying = glsl_es_300 ? QByteArrayLiteral("in") :
QByteArrayLiteral("varying");
textureLookup = glsl_es_300 ? QByteArrayLiteral("texture") :
QByteArrayLiteral("texture2D");
output = glsl_es_300 ? QByteArrayLiteral("fragColor") :
QByteArrayLiteral("gl_FragColor");
}
In general each and every function one uses needs to be verified whether they
exist in GLES and in which version. GLSL is a mess in that regard. I hate it
that you need to write your code four times and that's why KWin mostly
generates the code nowadays.
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128426/#review97302
-----------------------------------------------------------
On July 12, 2016, 1:34 a.m., David Edmundson wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128426/
> -----------------------------------------------------------
>
> (Updated July 12, 2016, 1:34 a.m.)
>
>
> Review request for KDE Frameworks and Plasma.
>
>
> Repository: plasma-framework
>
>
> Description
> -------
>
> Qt has two shaders for all items; one for when running OpenGL3.2+ without
> backwards compatibility (i.e running CoreProfile) and one that supports more
> legacy systems. (see
> the shaders directory and the versions ending with _core)
>
> core profile is only used if explicitly by the app enabled when creating the
> GL context.
>
> Something we don't currently do in Plasma, but a 3d party user could be doing.
>
> Long term it's also something I want to do in Plasma optionally as it gives a
> 15Mb memory saving with Mesa.
>
> This patch updates our material to provide the right shader for the
> given version matching the behavior of
> QSGShaderSourceBuilder::resolveShaderPath which Qt uses internally.
>
>
> Diffs
> -----
>
> src/declarativeimports/core/fadingnode.cpp
> 88b7310641f58c2b74fe61d2c5a97847cf7dc3b8
>
> Diff: https://git.reviewboard.kde.org/r/128426/diff/
>
>
> Testing
> -------
>
> ran krunner with
> + QSurfaceFormat format;
> + format.setVersion(3,2);
> + format.setProfile(QSurfaceFormat::CoreProfile);
> + QSurfaceFormat::setDefaultFormat(format);
>
> and it still works.
>
> plasmashell unchanged (so still requesting an GL 2.0 context) also still
> works.
>
>
> Thanks,
>
> David Edmundson
>
>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
