The old comment was for the location not the offset, we now use
the field for block members so mention that also.
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
In this patch we also copy the offset value from the ast and
implement offset linking rules by adding it to the record_compare()
function.
From Section 4.4.5 (Uniform and Shader Storage Block Layout Qualifiers)
of the GLSL 4.50 spec:
"Two blocks linked together in the same program with the same block
name must have the exact same set of members qualified with
offset and their integral-constant-expression values must be the
same, or a link-time error results."
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This implements the rules for the offset qualifier on block members.
From Section 4.4.5 (Uniform and Shader Storage Block Layout Qualifiers)
of the GLSL 4.50 spec:
"The offset qualifier can only be used on block members of blocks
declared with std140 or std430 layouts."
...
"It is a compile-time error to specify an offset that is smaller than
the offset of the previous member in the block or that lies within the
previous member of the block."
...
"The specified offset must be a multiple of the base alignment of the
type of the block member it qualifies, or a compile-time error results."
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Global in validation is already handled, this will do the validation
for variables, blocks and block members.
This fixes some CTS tests for the new enhanced layouts transform
feedback qualifiers.
V2: add some more valid input flags
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Previously interface blocks were giving the global default flags of
uniform blocks. This meant we could not check for invalid qualifiers
on interface blocks because they always contained invalid flags.
This changes parsing so that interface blocks now get an empty
set of layouts.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
If the following patch we will stop setting these layouts by default
on interface blocks, so we need to do this to avoid hitting the
assert.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
When BaseLevel > 0, we magnify the dimensions to fill out the size of
miplevels [0..BaseLevel). In particular, this was magnifying depth,
thinking that the depth doubles at each level. This is perfectly
reasonable for 3D textures, but dead wrong for array textures.
Changing the depth != 1 condition to a target == GL_TEXTURE_3D check
should make this only happen in the appropriate cases.
Fixes about 32 dEQP tests:
- dEQP-GLES31.functional.texture.gather.*.level_{1,2}
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
opt_vector_float() transforms several scalar MOV operations to a single
vectorial MOV.
This is done when those MOV covers all the components of the destination
register. So something like:
mov vgrf3.0.xy:D, 0D
mov vgrf3.0.w:D, 1065353216D
mov vgrf3.0.z:D, 0D
is transformed in:
mov vgrf3.0:F, [0F, 0F, 0F, 1F]
But there are cases where not all the components are written. For
example, in:
mov vgrf2.0.x:D, 1073741824D
mov vgrf3.0.xy:D, 0D
mov vgrf3.0.w:D, 1065353216D
mov vgrf4.0.xy:D, 1065353216D
mov vgrf4.0.w:D, 0D
mov vgrf6.0:UD, u4.xyzw:UD
Nor vgrf3 nor vgrf4 .z components are written, so the optimization is
not applied.
But it could be applied anyway with the components covered, using a
writemask to select the ones written. So we could transform it in:
mov vgrf2.0.x:D, 1073741824D
mov vgrf3.0.xyw:F, [0F, 0F, 0F, 1F]
mov vgrf4.0.xyw:F, [1F, 1F, 0F, 0F]
mov vgrf6.0:UD, u4.xyzw:UD
This commit does precisely that: opportunistically apply
opt_vector_float() when possible.
total instructions in shared programs: 7124660 -> 7114784 (-0.14%)
instructions in affected programs: 443078 -> 433202 (-2.23%)
helped: 4998
HURT: 0
total cycles in shared programs: 64757760 -> 64728016 (-0.05%)
cycles in affected programs: 1401686 -> 1371942 (-2.12%)
helped: 3243
HURT: 38
v2: change vectorize_mov() signature (Matt).
v3: take in account predicates (Juan).
v4 [mattst88]: Update shader-db numbers. Fix some whitespace issues.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
screen may still be used by other resources that are not yet freed.
To correctly fix this there will be a need to account for resources
differently, but this quick fix is not any worse than the original
code that leaked screens anyway.
Reviewed-by: Brian Paul <brianp@vmware.com>
No shader-db changes, but does recognize some extract_u16 which enables
the next patch to optimize some code.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Two shaders that appear in Unigine benchmarks (Heaven and Valley) unpack
three bytes from an integer and convert each into a float:
float((val >> 16u) & 0xffu)
float((val >> 8u) & 0xffu)
float((val >> 0u) & 0xffu)
Instead of shifting, masking, and type converting like this:
shr(8) g15<1>UD g25<8,8,1>UD 0x00000010UD
and(8) g16<1>UD g15<8,8,1>UD 0x000000ffUD
mov(8) g17<1>F g16<8,8,1>UD
shr(8) g18<1>UD g25<8,8,1>UD 0x00000008UD
and(8) g19<1>UD g18<8,8,1>UD 0x000000ffUD
mov(8) g20<1>F g19<8,8,1>UD
and(8) g21<1>UD g25<8,8,1>UD 0x000000ffUD
mov(8) g22<1>F g21<8,8,1>UD
i965 can simply extract a byte and convert to float in a single
instruction:
mov(8) g17<1>F g25.2<32,8,4>UB
mov(8) g20<1>F g25.1<32,8,4>UB
mov(8) g22<1>F g25.0<32,8,4>UB
This patch implements the first step: recognizing byte extraction. A
later patch will optimize out the conversion to float.
instructions in affected programs: 28568 -> 27450 (-3.91%)
helped: 7
cycles in affected programs: 210076 -> 203144 (-3.30%)
helped: 7
This patch decreases the number of instructions in the two Unigine
programs by:
#1721: 4520 -> 4374 instructions (-3.23%)
#1706: 3752 -> 3582 instructions (-4.53%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This resolves some order dependencies between the already existing
callback the newly created one.
Tested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is a limit of 10 display connections, which was a
problem for apps/tests that were continuously opening/closing display
connections.
This fix uses XAddExtension() and XESetCloseDisplay() to keep track
of the status of the display connections from the X server, freeing
mesa-related data as X displays get destroyed by the X server.
Poster child is the VTK "TimingTests"
Tested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
glXCreatePixmap() may specify a GLX_TEXTURE_FORMAT_RGB_EXT format
for an RGBA resource, causing us to create an RGBX view for an
RGBA resource, a combination vgpu10 does not support.
When this is detected, change the request to create an RGBA view
instead.
Reviewed-by: Brian Paul <brianp@vmware.com>
With this patch, make sure the shader resource view is properly created
before referencing it in the generate mipmap command.
Reviewed-by: Brian Paul <brianp@vmware.com>
If running with a software renderer backend, the timeout may be
insufficient, and we don't want to release busy buffers too early.
In practice, SVGA gpu lockups are extremely rare.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviwed-by: Brian Paul <brianp@vmware.com>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
dEQP-GLES31.functional.fbo.no_attachments.maximums.{all,height,size,width}
started hitting assertion failures when emitting SURFACE_STATE, after
commit e8fd60e789 where Samuel increased the maximum viewport size to
32768, from 16384.
MaxFramebufferWidth/Height were being set to the maximum viewport size,
but are actually limited by the SURFACE_STATE width/height field range,
which is 16384 on Gen7+ (where ARB_framebuffer_no_attachments is
exposed). So, reduce these to 16384 explicitly.
Fixes assert fails in the above mentioned dEQP tests. (Those tests
still fail, however.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
The adjusted polynomial coefficients come from the numerical
minimization of the L2 norm of the relative error. The old
coefficients would give a maximum relative error of about 15000 ULP in
the neighborhood around acos(x) = 0, the new ones give a relative
error bounded by less than 2000 ULP in the same neighborhood.
Fixes four dEQP subtests:
dEQP-GLES31.functional.shaders.builtin_functions.precision.acos.
highp_compute.{scalar,vec2,vec3,vec4}
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This will allow us to share the implementation while using different
polynomials for asin() and acos().
Francisco Jerez did this in the SPIR-V front-end; I'm merely porting
his idea to the GLSL world.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
From section 6.2 ("State Tables") of the GL 2.1 specification
(the text also appears in the GL 3.0 and ES 3.1 specifications):
"However, state variables for which IsEnabled is listed as the query
command can also be obtained using GetBooleanv, GetIntegerv, GetFloatv,
and GetDoublev."
GL_DEBUG_OUTPUT, GL_DEBUG_OUTPUT_SYNCHRONOUS, and GL_FRAGMENT_SHADER_ATI
were missing from the glGet*() functions. All other IsEnabled() pnames
look to be present, as far as I can tell.
Fixes 8 dEQP-GLES31.functional.debug.state_query subtests:
debug_output[_synchronous]_get{boolean,float,integer,integer64}.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
dEQP-GLES31.functional.debug.state_query.debug_group_stack_depth_*
tries to call glGet on GL_DEBUG_GROUP_STACK_DEPTH right away, before
doing any other debug setup. This should return 1.
However, because ctx->Debug wasn't allocated, we bailed and returned 0.
This patch removes the open-coded locking and switches the two glGet
functions to use _mesa_lock_debug_state(), which takes care of
allocating and initializing that state on the first time. It also
conveniently takes care of unlocking on failure for us, so we don't
need to handle that in every caller.
Fixes dEQP-GLES31.functional.debug.state_query.debug_group_stack_depth_
{getboolean,getfloat,getinteger,getinteger64}.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Support in Mesa main and i965 has just been added.
v2: Include note in 'New Features' of docs/relnotes/11.3.0.html.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This pname is tricky. The spec states that an internal format should be
returned, that is compatible with the passed internal format, and has
at least the same precision. There is no clear API to resolve this.
The closest we have (and what other drivers (i.e, NVidia proprietary) do,
is to return the same internal format given as parameter. But we validate
first that the passed internal format is supported by i965.
To check for support, we have the TextureFormatSupported map'. But
this map expects a 'mesa_format', which takes a format+typen. So, we must
first "come up" with a generic type that is suited for this internal format,
then get a mesa_format, and then do the validation.
The cleanest solution here is to add a method that does exactly what
the spec wants: a driver's preferred internal format from a given
internal format. But at this point we lack a clear view of what
defines this preference, and also there seems to be no API for it.
Reviewed-by: Dave Airlie <airlied@redhat.com>
_mesa_format_from_format_and_type() is currently not considering DEPTH and
STENCIL formats, which are not array formats and are not handled anywhere.
This patch adds cases for common combinations of DEPTH/STENCIL format and
types.
Reviewed-by: Dave Airlie <airlied@redhat.com>
We call the driver to provide its preferred type, but also provide a
default implementation that selects a generic type based on the passed
internal format.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This is supported since very early version of OpenGL, but we still call the
driver to give it the opportunity to report caveat or no support.
Reviewed-by: Dave Airlie <airlied@redhat.com>
It discards out the targets and internalformats that explicitly
mention (per-spec) that doesn't support filter types other than
NEAREST or NEAREST_MIPMAP_NEAREST. Those are:
* Texture buffers target
* Multisample targets
* Any integer internalformat
For the case of multisample targets, it was used the existing method
_mesa_target_allows_setting_sampler_parameter. This would scalate
better in the future if new targets appear that doesn't allow to
set sampler parameters.
We consider RENDERBUFFER to support LINEAR filters, because although
it doesn't support this filter for sampling, you can set LINEAR
on a blit operation using glBlitFramebuffer.
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- FRAMEBUFFER_RENDERABLE: The support for rendering to the resource via
framebuffer attachment is returned in <params>.
- FRAMEBUFFER_RENDERABLE_LAYERED: The support for layered rendering to
the resource via framebuffer attachment is returned in <params>.
- FRAMEBUFFER_BLEND: The support for rendering to the resource
via framebuffer attachment when blending is enabled is returned in
<params>."
For all of them,
"Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource is unsupported, NONE is returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- TEXTURE_SHADOW: The support for using the resource with shadow samplers
is written to <params>.
- TEXTURE_GATHER: The support for using the resource with texture gather
operations is written to <params>.
- TEXTURE_GATHER_SHADOW: The support for using resource with texture gather
operations with shadow samplers is written to <params>."
For all of them,
"Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource or operation is not supported, NONE is returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- TEXTURE_VIEW: The support for using the resource with the TextureView
command is returned in <params>.
Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource or operation is not supported, NONE is returned.
- VIEW_COMPATIBILITY_CLASS: The compatibility class of the resource when
used as a texture view is returned in <params>. The compatibility
class is one of the values from the /Class/ column of Table 3.X.2. If
the resource has no other formats that are compatible, the resource
does not support views, or if texture views are not supported, NONE is
returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
It will be used by the ARB_internalformat_query2 implementation to
implement the VIEW_COMPATIBILITY_CLASS <pname> query.
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- CLEAR_BUFFER: The support for using the resource with ClearBuffer*Data
commands is returned in <params>.
Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource or operation is not supported, NONE is returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- TEXTURE_COMPRESSED: If <internalformat> is a compressed format
that is supported for this type of resource, TRUE is returned in
<params>. If the internal format is not compressed, or the type of
resource is not supported, FALSE is returned.
- TEXTURE_COMPRESSED_BLOCK_WIDTH: If the resource contains a compressed
format, the width of a compressed block (in bytes) is returned in
<params>. If the internal format is not compressed, or the resource
is not supported, 0 is returned.
- TEXTURE_COMPRESSED_BLOCK_HEIGHT: If the resource contains a compressed
format, the height of a compressed block (in bytes) is returned in
<params>. If the internal format is not compressed, or the resource
is not supported, 0 is returned.
- TEXTURE_COMPRESSED_BLOCK_SIZE: If the resource contains a compressed
format the number of bytes per block is returned in <params>. If the
internal format is not compressed, or the resource is not supported,
0 is returned.
(combined with the above, allows the bitrate to be computed, and may be
useful in conjunction with ARB_compressed_texture_pixel_storage)."
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- SIMULTANEOUS_TEXTURE_AND_DEPTH_TEST: The support for using the resource
both as a source for texture sampling while it is bound as a buffer for
depth test is written to <params>. For example, a depth (or stencil)
texture could be bound simultaneously for texturing while it is bound as
a depth (and/or stencil) buffer without causing a feedback loop, provided
that depth writes are disabled.
- SIMULTANEOUS_TEXTURE_AND_STENCIL_TEST: The support for using the resource
both as a source for texture sampling while it is bound as a buffer for
stencil test is written to <params>. For example, a depth (or stencil)
texture could be bound simultaneously for texturing while it is bound as
a depth (and/or stencil) buffer without causing a feedback loop,
provided that stencil writes are disabled.
- SIMULTANEOUS_TEXTURE_AND_DEPTH_WRITE: The support for using the resource
both as a source for texture sampling while performing depth writes to
the resources is written to <params>. For example, a depth-stencil
texture could be bound simultaneously for stencil texturing while it
is bound as a depth buffer. Feedback loops cannot occur because sampling
a stencil texture only returns the stencil portion, and thus writes to
the depth buffer do not modify the stencil portions.
- SIMULTANEOUS_TEXTURE_AND_STENCIL_WRITE: The support for using the resource
both as a source for texture sampling while performing stencil writes to
the resources is written to <params>. For example, a depth-stencil
texture could be bound simultaneously for depth-texturing while it is
bound as a stencil buffer. Feedback loops cannot occur because sampling
a depth texture only returns the depth portion, and thus writes to
the stencil buffer could not modify the depth portions.
For all of them,
"Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource or operation is not supported, NONE is returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
