| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
It is unused.
|
| |
|
|
|
|
| |
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
|
| |
|
|
|
|
|
|
|
|
|
| |
meta_renderer_native_gles3_read_pixels() was assuming that the target
buffer stride == width * 4. This is not generally true. When a DRM
driver allocates a dumb buffer, it is free to choose a stride so that
the buffer can actually work on the hardware.
Record the driver chosen stride in MetaDumbBuffer, and use it in the CPU
copy path. This should fix any possible stride issues in
meta_renderer_native_gles3_read_pixels().
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When the buffer modifier is DRM_FORMAT_MOD_LINEAR, we can use the
old code path. That means not specifying any modifier parameter.
It was an issue when the primary GPU was creating a linear GBM surface
and that a secondary GPU (not supporting modifiers) was trying to
import it. It was failing because the driver could not use the
import_modifiers extension even though it could in theory easily
import the buffer.
https://gitlab.gnome.org/GNOME/mutter/issues/18
|
| |
|
|
|
|
| |
There was a typo for modifier parameter of planes 1 & 2.
https://gitlab.gnome.org/GNOME/mutter/issues/18
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have the list of supported modifiers from the monitor
manager (via the CRTCs to the primary planes), we can use this to inform
EGL it can use those modifiers to allocate the GBM surface with. Doing
so allows us to use tiling and compression for our scanout surfaces.
This requires the Mesa commit in:
Mesa 10.3 (08264e5dad4df448e7718e782ad9077902089a07) or
Mesa 10.2.7 (55d28925e6109a4afd61f109e845a8a51bd17652).
Otherwise Mesa closes the fd behind our back and re-importing will fail.
See FDO bug #76188 for details.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
|
| |
|
|
|
|
|
|
|
| |
On some architectures, including both GLES3/gl3.h GL/gl.h will cause
compilation issues due to incompatible type definitions. To avoid
running into that issue while building on other architectures, make
sure we haven't included GL/gl.h by accident.
https://bugzilla.gnome.org/show_bug.cgi?id=788695
|
| |
|
|
|
|
| |
They caused conflicts on i686 as GL/gl.h was included by cogl.
https://bugzilla.gnome.org/show_bug.cgi?id=788695
|
| |
|
|
|
|
| |
It wasn't used for anything, so don't pass it.
https://bugzilla.gnome.org/show_bug.cgi?id=788695
|
|
|
A hybrid GPU system is a system where more than one GPU is connected to
connectors. A common configuration is having a integrated GPU (iGPU)
connected to a laptop panel, and a dedicated GPU (dGPU) connected to
one or more external connector (such as HDMI).
This commit adds support for rendering the compositor stage using the
iGPU, then copying the framebuffer content onto a secondary framebuffer
that will be page flipped on the CRTC of the dGPU.
This can work in two different ways: GPU accelerated using Open GL ES
3, or CPU unaccelerated.
When supported, GPU accelerated copying works by exporting the iGPU
onscreen framebuffer as a DMA-BUF, importing it as a texture on a
separate dGPU EGL context, then using glBlitFramebuffer(), blitting it
onto a framebuffer on the dGPU that can then be page flipped on the dGPU
CRTC.
When GPU acceleration is not available, copying works by creating two
dumb buffers, and each frame glReadPixels() from the iGPU EGL render
context directly into the dumb buffer. The dumb buffer is then page
flipped on the dGPU CRTC.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
|
