Vasily Khoruzhick authored 2 years ago and Konstantin committed 2 years ago

ARB_blend_func_extended may be exposed even without GLSL 1.30.
In order to use it we need GLES2 shaders that are available if
ARB_ES2_compatibility is exposed.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

Yuriy Vasilev authored 3 years ago and Konstantin committed 2 years ago

In GLES2, we cannot do GL_RED or GL_RG without GL_EXT_texture_rg.
So, add check for GL_EXT_texture_rg to make it working. Also add
a yuv2 pixman format into render.h to make Xv yuv rendering works.

Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

For 24 and 32 bit depth pictures xserver uses PICT_x8r8g8b8 and PICT_a8r8g8b8 formats,
which must be backed with GL_BGRA format. It is present in OpenGL ES 2.0 only with
GL_EXT_texture_format_BGRA8888 extension. We require such extension in glamor_init,
so, why not to make use of it?
Fixes #1208
Fixes #1354

Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

Adam Jackson authored 3 years ago and Povilas Kanapickas committed 3 years ago

Reviewed-by: Emma Anholt <emma@anholt.net>

Adam Jackson authored 3 years ago and Povilas Kanapickas committed 3 years ago

There's no real benefit to using GLX, and the other DDXes are using EGL
already, so let's converge on EGL so we can concentrate the fixes in one
place.

We go to some effort to avoid being the thing that requires libX11 here.
We prefer EGL_EXT_platform_xcb over _x11, and if forced to use the
latter we'll ask the dynamic linker for XGetXCBConnection and
XOpenDisplay rather than link against xlib stuff ourselves. Xephyr is
now a pure XCB application if it can be.

Reviewed-by: Emma Anholt <emma@anholt.net>

Since 8702c938 the pixmap formats are
handled in a single place. In the process of conversion the difference
between pixmap formats that can be uploaded and those that can be
rendered on GL side has been lost. This affects only 1-bit pixmaps: as
they aren't supported on GL, but can be converted to a R8 or A8 format
for rendering (see glamor_get_tex_format_type_from_pictformat()).

To work around this we add a separate flag that specifies whether the
format actually supports rendering in GL, convert all checks to use this
flag and then add 1-bit pixmap formats that don't support rendering in
GL.

Fixes: 8702c938
Closes: xorg/xserver#1210


Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

This enables a number of the GLSL 1.30 paths on GPUs that have
EXT_gpu_shader4 but don't have GLSL 1.30 exposed.

(Intel gen4/5 mainly)

Reviewed-by: Adam Jackson <ajax@redhat.com>

This should make adding gpu shader4 support cleaner

Reviewed-by: Adam Jackson <ajax@redhat.com>

Like in 0e3f1252 ("glamor: Avoid using GL_QUADS on VC4")
this will avoid mesa to fallback doing conversion for QUADS primitives.

Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

Currrently, when a GL error is triggered, glamor would log the error
which may not be sufficient to trace it back to the cause of the error.

Also dump the backtrace which may give more information as to where the
error comes from.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
#1156

Adam Jackson authored 4 years ago and Adam Jackson committed 4 years ago

You will not find GL_ARB_* extensions in a GLES context by definition,
the droid you're looking for is named GL_KHR_debug.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Most (but not all) of these were found by using
  codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

It can't be used with older GLSL. Fixes a crash when attempting to
anyway.

Closes: #97


Fixes: e7308b6c "glamor: Add support for CA rendering in a single pass."
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Dor Askayo authored 5 years ago and Michel Dänzer committed 5 years ago

When a pixmap is created with a backing FBO, the FBO should be cleared
to avoid rendering uninitialized memory. This could happen when the
pixmap is rendered without being filled in its entirety.

One example is when a top-level window without a background is
resized. The pixmap would be reallocated to prepare for more pixels,
but uninitialized memory would be rendered in the resize offset until
the client sends a frame that fills these additional pixels.

Another example is when a new top-level window is created without a
background. Uninitialized memory would be rendered after the pixmap is
allocated and before the client sends its first frame.

This issue is only apparent in OpenGL implementations that don't zero
the VRAM of allocated buffers by default, such as RadeonSI.

Signed-off-by: Dor Askayo <dor.askayo@gmail.com>
Closes: xorg/xserver#636


Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Caused assertion failures / crashes with Xorg.

Closes: #916

DDX such as Xorg, Xwayland & Xephyr do not destroy the pixmap before
they call into CloseScreen. At the same time Xvfb (support for glamor
coming with later commit) do.

As such the pixmap will be NULL and we'll crash out.

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

Olivier Fourdan authored 6 years ago and Adam Jackson committed 5 years ago

Chnage the API for `glamor_set_pixmap_texture()` to return a status,
so that the caller can know whether it succeeded or not.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

Emma Anholt authored 5 years ago and Adam Jackson committed 5 years ago

We had various helper functions trying to come up with the
internalformat/format/type/render formats for pixmaps, and it's much
nicer to just detect what those should be once at startup.  This gives
us a chance to do the right thing for GLES.

It also, notably, fixes our format/type for depth 15 and 16 setup for
desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most
drivers instead of 32bpp (GL_RGB/UBYTE).

GLES still has regressions over desktop (2 regressions in llvmpipe
XTS, many in rendercheck), but I think this is a good baseline.

Signed-off-by: Eric Anholt <eric@anholt.net>

Emma Anholt authored 5 years ago and Adam Jackson committed 5 years ago

For GLES, we're going to need a lot more logic for picking the
iformat/format/type of texture setup, so we'll want the pixmap's depth
and is_cbcr flag.

Signed-off-by: Eric Anholt <eric@anholt.net>

Emma Anholt authored 5 years ago and Adam Jackson committed 5 years ago

"format" is a bit of a confused term (internalformat vs GL format),
and all we really needed was "is this GL_RED?"

Signed-off-by: Eric Anholt <eric@anholt.net>

Emma Anholt authored 5 years ago and Adam Jackson committed 5 years ago

There are only 2 flavors we are distinguishing -- GL versions are
handled separately.

Signed-off-by: Eric Anholt <eric@anholt.net>

Olivier Fourdan authored 6 years ago and Emma Anholt committed 6 years ago

If `_glamor_create_tex()` fails to allocate the FBO because of
GL_OUT_OF_MEMORY error, the `pixmap_priv->fbo` is NULL.

However, `glamor_get_pixmap_texture()` doesn't actually check whether
the `pixmap_priv->fbo` is NULL and will segfault with a NULL pointer
dereference trying to access the `pixmap_priv->fbo->tex`.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: #647

Julien Isorce authored 6 years ago and Adam Jackson committed 6 years ago

Allow to upload the CbCr plane of an NV12 image into a GL texture.

Signed-off-by: Julien Isorce <jisorce@oblong.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

When support for allocating GBM BOs with modifiers was added,
glamor_fd_from_pixmap() was changed so that it would return an error if
it got a bo with modifiers set from glamor_fds_from_pixmap(). The
problem is that on systems that support BOs with modifiers,
glamor_fds_from_pixmap() will always return BOs with modifiers.

This means that glamor_fd_from_pixmap() was broken entirely, which broke
a number of other things including glamor_shareable_fd_from_pixmap(),
which meant that modesetting using multiple GPUs with the modesetting
DDX was also broken. Easy reproducer:

- Find a laptop with DRI prime that has outputs connected to the
  dedicated GPU and integrated GPU
- Try to enable one display on each using the modesetting DDX
- Fail

Since there isn't a way to ask for no modifiers from
glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
function used by both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Fixes: c8c276c9 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")

glamor_fds_from_pixmap returns 0 on error, but we were treating that as
success, continuing with uninitialized stride and fd values.

Also bail if the offset isn't 0, same as in dri3_fd_from_pixmap.

v2:
* Reduce to a simple one-liner fix (Emil Velikov)

Fixes: c8c276c9 "glamor: Implement PixmapFromBuffers and
                     BuffersFromPixmap"
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

This matches what glamor_egl_fds_from_pixmap and dri3_fds_from_pixmap do
and what proc_dri3_buffers_from_pixmap expects.

Fixes: c8c276c9 "glamor: Implement PixmapFromBuffers and
                     BuffersFromPixmap"
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

Lukas F. Hartmann authored 6 years ago and Adam Jackson committed 6 years ago

Hi,

I upgraded Xwayland and the assorted libraries from git masters today,
and noticed that glamor wouldn't work anymore on i.MX6/etnaviv. The
error was:

No provider of glVertexAttribDivisor found.  Requires one of:
    Desktop OpenGL 3.3
    OpenGL ES 3.0
    GL extension "GL_ANGLE_instanced_arrays"
    GL extension "GL_ARB_instanced_arrays"
    GL extension "GL_EXT_instanced_arrays"
    GL extension "GL_NV_instanced_arrays"

The problem is that etnaviv offers GLSL 140 on GL 2.1 and glamor
rendering assumes that glVertexAttribDivisor() is always available on
GLSL>=130, which is not the case here. Forcing GLSL 120 makes glamor
work fine again on this platform. After chatting with ajax in
#xorg-devel, the following solution was proposed.

This is my first time of submitting a patch, so please excuse me and
advise if I'm doing it wrong ;)

Cheers
Lukas (mntmn)
Reviewed-by: Eric Anholt <eric@anholt.net>

Emma Anholt authored 6 years ago and Adam Jackson committed 6 years ago

We were mixing stdint and CARD* types, causing compiler warnings on
32-bit.  Just switch over to stdint, which is what we'd like the server
to be using long term, anyway.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>

Michel Dänzer authored 7 years ago and Adam Jackson committed 7 years ago

They're part of the 1.20 RC1 ABI, and actually used by external drivers.
Also, requiring drivers which don't support the new functionality in
DRI3 1.2 to switch to the new interfaces seems unreasonable.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

Louis-Francis Ratté-Boulianne authored 7 years ago and Adam Jackson committed 7 years ago

Implement function added in DRI3 v1.1.

A newest version of libepoxy (>= 1.4.4) is required as earlier
versions use a problematic version of Khronos
EXT_image_dma_buf_import_modifiers spec.

v4: Only send scanout-supported modifiers if flipping is possible
v5: Fix memory corruption in XWayland (uninitialized pointer)

Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>

Louis-Francis Ratté-Boulianne authored 7 years ago and Adam Jackson committed 7 years ago

It relies on GBM >= 17.1.0 where we can import BO with multiple
planes and a format modifier (GBM_BO_IMPORT_FD_MODIFIER).

v2: Properly free fds in Xwayland

[Also add glamor_egl_ext.h to Makefile.am for distcheck's sake - ajax]

Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>

Mario Kleiner authored 7 years ago and Adam Jackson committed 7 years ago

This makes it work properly with OpenGL based desktop
compositing, as tested with EGL and GLX based compositing
under OpenGL-2/3, and also artifact free with XRender
based 2D compositing.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>

GLES spells this extension as GL_OES_vertex_array_object, but it is
functionally equivalent to the GL_ARB version. Mesa has supported both
since 9.0, let's go ahead and require it.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

   text	   data	    bss	    dec	    hex	filename
2134764	  45210	 128704	2308678	 233a46	build/hw/kdrive/ephyr/Xephyr.before
2129972	  45210	 128704	2303886	 23278e	build/hw/kdrive/ephyr/Xephyr.after

Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

Effectively always true anyway.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

Improves Raspberry Pi 3 x11perf -copywinwin500 from ~480/sec to
~700/sec.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

All that was left here was updating the FBO's size.  However, the FBO
size was always set correctly already through
glamor_set_pixmap_texture() from whoever had attached a new BO to the
pixmap.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

This means we no longer get "s" for on-screen drawing in glamor_debug,
and there's only "m" (CPU memory) or "f" (Any GPU memory, aka FBOs).
That seems fine to me.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>