Review Request 128426: Support OpenGL 3.2 Core profile in FadingNode shaders

[Martin Gräßlin]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160712/432d387a/attachment.html>