Re: opengl and the compositor
Roman Gilg <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kwin |
|---|---|
| Message-ID | <CAJcyoyuuepoEPbea4t5AfAaugAXsbWDXG-hdmO3VrRLi6PZnmw@mail.gmail.com> |
On Mon, Nov 18, 2019 at 8:50 AM Sampsa Riikonen <[email protected]> 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