GitLab

The intent is to use this extension on vc4 to allow X11 to do overlapping
CopyArea() within a pixmap without first blitting the pixmap to a
temporary.  With associated glamor patches, improves x11perf
-copywinwin100 performance on a Raspberry Pi 3 from ~4700/sec to
~5130/sec, and is an even larger boost to uncomposited window movement
performance (most copywinwin100 copies don't overlap).

v2: Fix glIsEnabled() on the new enums.
v3: Drop the local spec since I'm upstreaming the spec.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

v2: use !! in the function to be explicit about type conversion.  Though,
gcc generates the same code with or without the logical !!.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

Try to start removing things from the cluttered imports.h file.

v2: add new header to Makefile.sources
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

Before we were doing RGBA4 on GLES3 only, but as of GLES2 2.0.22 it should
be RGBA4 as well.  Fixes DEQP
functional.state_query.rbo.renderbuffer_internal_format.
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

This extension is effectively a backport of GLES3's internalformat
handling to GLES 1/2.  It guarantees that sized internalformats specified
for textures and renderbuffers have at least the specified size stored.
That's a pretty minimal requirement, so I think it can be dummy_true and
exposed as a standard in Mesa.

As a side effect, it also allows GL_RGB565 to be specified as a texture
format, not just as a renderbuffer.  Mesa had previously been allowing 565
textures, which angered DEQP in the absence of this extension being
exposed.

v2: Allow 2101010rev with sized internalformats even on GLES3, citing the
    extension spec.  Extend extension checks for GLES2 contexts exposing
    with texture_float, texture_half_float, and texture_rg.
v3: Fix ALPHA/LUMINANCE/LUMINANCE_ALPHA error checking (GLES3 CTS
    failures)
v4: Mark GL_RGB10 non-color-renderable on ES, fix A/L/LA errors on GLES2
    with float formats.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

Previously, we were downconverting to 8888 automatically if the hardware
didn't suport it.  However, with the advent of
GL_OES_required_internalformat, we have to actually store the
internalformats we advertise support for.  And, it seems rather
disingenuous to advertise the extension if we don't actually support it.

v2: Throw an error when using the format on ES2 without the extension present.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

For supporting RGB5 in hardware with A in the low bit (vc4), we need this
format as well.

v2: Add proper _mesa_format_matches_format_and_type() support (from
    Nicolai).

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)

This can happen with surface-based texture objects derived from EGL
images, since those aren't immutable.

Fixes tests in dEQP-EGL.functional.sharing.gles2.multithread.random.images.teximage2d.* and others
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

This gets pretty much the entire classic tree building, as well as
i965, including the various glapis. There are some workarounds for bugs
that are fixed in meson 0.43.0, which is due out on October 8th.

I have tested this with piglit using glx.

v2: - fix typo "vaule" -> "value"
    - use gtest dep instead of linking to libgtest (rebase error)
    - use gtest dep instead of linking against libgtest (rebase error)
    - copy the megadriver, then create hard links from that, then delete
      the megadriver. This matches the behavior of the autotools build.
      (Eric A)
    - Use host_machine instead of target_machine (Eric A)
    - Put a comment in the right place (Eric A)
    - Don't have two variables for the same information (Eric A)
    - Put pre_args at top of file in this patch (Eric A)
    - Fix glx generators in this patch instead of next (Eric A)
    - Remove -DMESON hack (Eric A)
    - add sha1_h to mesa in this patch (Eric A)
    - Put generators in loops when possible to reduce code in
      mapi/glapi/gen (Eric A)
v3: - put HAVE_X11_PLATFORM in this patch
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

When a texture is immutable, we can't tack on extra levels
after-the-fact like we could with glTexImage. So check against that
level limit and return an error if it's surpassed.

This fixes:
KHR-GL45.geometry_shader.layered_fbo.fb_texture_invalid_level_number

(Based on a patch by Ilia Mirkin.)

Reviewed-by: Antia Puentes <apuentes@igalia.com> [imirkin v2]
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

Found while trying to optimize an application.

Not observed to help performance on i965, but should at least reduce
the memory usage of such textures a bit.
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Eero Tamminen <eero.t.tamminen@intel.com>

Found with MinGW optimized build.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>

Found with MinGW optimized build.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Now never null!
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

When this file is included by Gallium, the fprintf causes it to fail to
compile. This is an unreachable error case, and we shouldn't be calling
fprintf directly.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

This file will be #included, so the functions should be static.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Has been disabled for 12 years.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Imported from master (commit ef07298391c6dcad843e0b13e985090c1dd76e76)
of https://cgit.freedesktop.org/~mareko/libtxc_dxtn/Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>

The EXT_texture_type_2_10_10_10_REV (ES only) states the following issue:

   "1. Should textures specified with this type be renderable?

    UNRESOLVED: No.  A separate extension could provide this functionality."

This partially fixes
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.{rgb,rgba}_unsigned_int_2_10_10_10_rev
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

ES requires it. This is a partial fix for
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb_unsigned_int_2_10_10_10_rev
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

It leads to surprising states with integer inputs and outputs on
vertex processing stages (e.g. geometry stages). Instead, rely on the
driver to choose smooth interpolation by default.

We still allow varyings to match when one stage declares it as smooth
and the other declares it without interpolation qualifiers.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>

Cc: 17.1 17.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This is already done for other programs stages, fixes a leak when using
compute programs.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102844Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

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

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

The spec has special rules for querying buffer offsets and sizes
when BindBufferBase is used, described  in the OpenGL 4.6 spec,
section 6.8 Buffer Object State:

   "To query the starting offset or size of the range of a buffer
    object binding in an indexed array, call GetInteger64i_v with
    target set to respectively the starting offset or binding size
    name from table 6.5 for that array. Index must be in the range
    zero to the number of bind points supported minus one. If the
    starting offset or size was not specified when the buffer object
    was bound (e.g. if it was bound with BindBufferBase), or if no
    buffer object is bound to the target array at index, zero is
    returned."

Transform feedback buffer queries should follow the same rules, since
it is the same case for them. There is a CTS test for this.

Fixes:
KHR-GL45.direct_state_access.xfb_buffers
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102530
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Alexandre Demers <alexandre.f.demers@gmail.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

Former is non-deterministic, results in non-reproducible builds and
compilers throw a warning about it.

Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>

The macro itself is a well defined string, which cannot cause issues
with printf or other printf-like functions.

All other places through Mesa already use it directly, so let's update
the final two instances.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>

GetTex*Image should return INVALID_ENUM if target is not valid, however,
GetTextureImage does not receive a target, and instead should return
INVALID_OPERATION if the effective target is not valid. From the
OpenGL 4.6 core profile spec, section 8.11 Texture Queries:

"An INVALID_OPERATION error is generated by GetTextureImage if the effective
 target is not one of TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY,
 TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY, TEXTURE_RECTANGLE, or
 TEXTURE_CUBE_MAP (for GetTextureImage only)."

Fixes:
KHR-GL45.direct_state_access.textures_image_query_errors
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

160->152.
Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

reduces size from 1144 to 1128.
Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

This reduces the size from 144 bytes to 128 bytes.
Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

This reduces this from 200->182 bytes.
Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

This reduces each of these by 8 bytes.
Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>