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>

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>

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

Drops from 40->32 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>

reduces both 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>

This makes these use 16-bytes instead of 24-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>

Semantically identical to the EXT version (whose string is still valid
for GLES), so rename the bit but expose both extension strings.
(Suggested by Ilia Mirkin and Ian Romanick.)

v3: Fix the entrypoint alias in GL4x.xml (Ilia)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>

The only difference from the EXT version is bumping the minmax to 16, so
just hit all the drivers at once.

v2: Fix driver names, add to 17.3 release notes (Ilia Mirkin)
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This will be used to enable the STD430 layout as the default for
UBOs and SSBOs with layouts of shared/packed rather than STD140.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

After the context is initialized, the API and context flags won't
change.  So, we can compute whether vertex attribute 0 aliases
vertex position just once.

This should make the glVertexAttrib*() functions a little quicker.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

These are just basic implementations.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

v2: use PIPE_CAP_MEMOBJ to guard the extension

v3 (Timothy Arceri):
 - expose extensions via the cap_mappings array
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

V2 (Timothy Arceri):
 - fix copy and paste error with error message

V3 (Timothy Arceri):
 - drop the Protected field for now as its unused
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

Used by EXT_external_objects and EXT_external_objects_fd

V2 (Timothy Arceri):
 - Throw GL_OUT_OF_MEMORY error if CreateMemoryObjectsEXT()
   fails.
 - C99 tidy ups
 - remove void cast (Constantine Kharlamov)

V3 (Timothy Arceri):
 - rename mo -> memObj
 - check that the object is not NULL before initializing
 - add missing "EXT" in function error message

V4 (Timothy Arceri):
 - remove checks for (memory objecy id == 0) and catch in
   _mesa_lookup_memory_object() instead.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

In Mesa we use the convention that if gl_renderbuffer::NumSamples
or gl_texture_image::NumSamples is zero, it's a non-MSAA surface.
Otherwise, it's an MSAA surface.  But in gallium nr_samples=1 is a
non-MSAA surface.

Before, if the user called glRenderbufferStorageMultisample() or
glTexImage2DMultisample() with samples=1 we skipped the search for the
next higher number of supported samples and asked the gallium driver to
create a surface with nr_samples=1.  So we got a non-MSAA surface.
This failed to meet the expection of the user making those calls.

This patch changes the sample count checks in st_AllocTextureStorage()
and st_renderbuffer_alloc_storage() to test for samples > 0 instead of > 1.
And we now start querying for MSAA support at samples=2 since gallium has
no concept of a 1x MSAA surface.

A specific example of this problem is the Piglit arb_framebuffer_srgb-blit
test.  It calls glRenderbufferStorageMultisample() with samples=1 to
request an MSAA renderbuffer with the minimum supported number of MSAA
samples.  Instead of creating a 4x or 8x, etc. MSAA surface, we wound up
creating a non-MSAA surface.

Finally, add a comment on the gl_renderbuffer::NumSamples field.

There is one piglit regression with the VMware driver:
ext_framebuffer_multisample-blit-mismatched-formats fails because
now we're actually creating 4x MSAA surfaces (the requested sample
count is 1) and we're hitting some sort of bug in the blitter code.  That
will have to be fixed separately.  Other drivers may find regressions
too now that MSAA surfaces are really being created.

v2: start quering for MSAA support with samples=2 instead of 1.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

This is useless.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

This allows us to drop the duplicate gl_uniform_block_packing enum.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

This has the benefit that we get to set up constants for exactly
the shader stage that needs it.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

There are several new driver flags here so that it maps nicely to gallium.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Now AlphaFunc avoids the blend state update in st/mesa and avoids
_mesa_update_state_locked.

The GL_ALPHA_TEST enable won't trigger blend state updates in st/mesa
after st/mesa stops relying on _NEW_COLOR.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

skipping _mesa_update_state_locked
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

not used
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

These are only used in the GL compatibility profile.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

This bypasses _mesa_update_state_locked.

Before:
   DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ stencil enable change:    3.99 million
   DrawArrays   ( 1 VBOs, 4 UBOs,  8 Tex) w/ stencil enable change:    4.56 million

After:
   DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ stencil enable change:    4.93 million
   DrawArrays   ( 1 VBOs, 4 UBOs,  8 Tex) w/ stencil enable change:    5.84 million

It's quite a difference in the draw call rate when ctx->NewState stays
equal to 0 the whole time.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

The idea is to remove the dependency on _mesa_update_state_locked,
so that st/mesa can skip it for stencil state updates, and then stop
setting _NEW_STENCIL in mesa/main if the driver is st/mesa.

The main motivation is to stop invoking _mesa_update_state_locked for
certain state groups.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>

Yes, ARB_bindless_texture allows to do this. In other words, in
a situation like:

layout (bindless_sampler) uniform sampler2D tex;

The 'tex' sampler uniform can be either set with glUniform1()
(old-style bound samplers) or with glUniformHandleui() (resident
handles).

When glUniform1() is used, we have to somehow make the texture
resident "under the hood". This is done by requesting a texture
handle to the driver, making the handle resident in the current
context and overwriting the value directly in the constant buffer.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>