opengl and the compositor

Roman Gilg subdiff at gmail.com
Sun Dec 8 19:13:40 GMT 2019


On Mon, Nov 18, 2019 at 8:50 AM Sampsa Riikonen <sampsa.riikonen at iki.fi> wrote:
>
> Dear Developers,
>
> Sorry about the basic nature of my questions.

Hi Sampsa,

no problem, thanks for getting in touch. I am sorry you had to wait a
bit on a reply.

> I'd like to get into kwin development, but before that, I have to get my
> head around some basic concepts.
>
> I'm recurring to this mailing list, since these thing is not explained
> anywhere (at least I could not find).
>
> Please feel free to point me to any tutorial or lines in the actual kwin
> source code.
>
> **How does an OpenGL context play along with the compositor?**
>
> Consider this:
>
> - I create a window with an opengl context
> - I draw stuff to that context using opengl 3.1 (texture streaming in my
> case)
> - Opengl renders the final 2d image into a framebuffer
> - ..that framebuffer is used by the kwin compositor, to embed it into
> the final desktop view (?)
> - But the opengl rasterization has been done on the GPU, and to my
> understanding, never "leaves the GPU"

Yes, in the best case we don't go via main memory.

On X this is handled by the XServer and some driver interfaces created
specifically for that case. With DRI you are already at the right
address for going deeper. But I would not recommend it. Instead if you
want to get in KWin development there are better paths to go. Later on
you can still look into this stuff.

On Wayland we use the Mesa internal wl_drm [1] and nowadays also the
dmabuf [2] protocols in a way [3] such they don't leave the GPU
memory.

[1] https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/egl/wayland/wayland-drm/wayland-drm.xml
[2] https://gitlab.freedesktop.org/wayland/wayland-protocols/blob/master/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
[3] https://cgit.kde.org/kwin.git/tree/platformsupport/scenes/opengl/egl_dmabuf.cpp#n287

> - ..so how is the compositor is able to use that framebuffer?
> - I typically use direct rendering in opengl, so this gets even more
> mystical (ref:
> https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure#/media/File:Linux_graphics_drivers_DRI_current.svg
> )
>
>
> **How are the Qt widgets rendered with the OpenGL backend?**
>
> The kwin compositor creates it own OpenGL context
>
> Is my understanding of the Qt rendering pipeline correct:?
>
> - My program creates a Qt widget under kwin
> - Those widgets have the window-manager-owned widgets as their parent
> widgets
> - Window manager renders the main level widgets (=> and hierarchically
> the child-level widgets created by my Qt program)

The Qt widgets in your program don't have window-manager-owned widgets
as parents, but things that are specific to the windowing system: your
program does not send Qt internal stuff to KWin, but in case of X11
Windows (or Pixmaps) to the XServer or in case of Wayland surfaces to
the Wayland server.

> - Window manager passes the final rendered widgets to OpenGL

To be more precise the window manager renders the windows/surfaces it
gets via OpenGl and sends the final rendered image of the whole screen
either to the XServer back in case of X11 or for example to the kernel
in case of Wayland via the kernel's DRM interface.

>
> Kind Regards,
>
> Sampsa Riikonen
>
>

You can also join us on #plasma or #kwin on Freenode IRC. Hope to see
you around!

Cheers
Roman


More information about the kwin mailing list