This is used by Android to select an eglconfig compatible with HWComposer.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Rob Herring <robh@kernel.org>
[Emil Velikov: add the _eglIsConfigAttribValid check]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Builds with gallium enabled fail on x86 with linker error:
external/mesa3d/src/mesa/vbo/vbo_exec_array.c:127: error: undefined reference to '_mesa_uint_array_min_max'
The problem is sse_minmax.c is not included in the libmesa_st_mesa
library. Since the SSE4.1 files are needed for both libmesa_st_mesa
and libmesa_dricore, move SSE4.1 files into a separate static library
that can be used by both.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This is an old patch I had around.
Vector selects seem to work well from LLVM 3.3. Using them should
improve code quality, as it might make constant propagation pass more
effective.
Tested lp_test_*
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Needed because not all the built-in variables are marked as system
values, so they still have the mode ir_var_auto. Right now it fixes
raising the warning when gl_GlobalInvocationID and
gl_LocalInvocationIndex are used.
v2: use is_gl_identifier instead of filtering for some names (Ilia
Mirkin)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is the same ext as ARB_draw_buffers_blend (plus some core
functionality that already exists). Add the alias entrypoints.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Haswell GT2 and GT3 have a minimum of 64 entries. Hardcoding 32
is not legal.
v2: Delete stale comment (caught by Alejandro).
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
According to the Sandybridge PRM's description of the resinfo message,
the .z value returned will be Depth == 0 ? 0 : Depth + 1. The earlier
PRMs have the same table.
This means we return 0 for array textures with a single slice, when
we ought to return 1. Just override it to max(depth, 1).
Fixes 10 dEQP-GLES3.functional tests on Sandybridge:
shaders.texture_functions.texturesize.sampler2darray_fixed_vertex
shaders.texture_functions.texturesize.sampler2darray_fixed_fragment
shaders.texture_functions.texturesize.sampler2darray_float_vertex
shaders.texture_functions.texturesize.sampler2darray_float_fragment
shaders.texture_functions.texturesize.isampler2darray_vertex
shaders.texture_functions.texturesize.isampler2darray_fragment
shaders.texture_functions.texturesize.usampler2darray_vertex
shaders.texture_functions.texturesize.usampler2darray_fragment
shaders.texture_functions.texturesize.sampler2darrayshadow_vertex
shaders.texture_functions.texturesize.sampler2darrayshadow_fragment
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Oddly, this did not affect the shader where I first noticed the pattern.
That particular shader doesn't get its if-statement converted to a bcsel
because there are two assignments in the else-statement. This led to me
submitting https://bugs.freedesktop.org/show_bug.cgi?id=94747.
shader-db results:
Sandy Bridge
total instructions in shared programs: 8467384 -> 8467069 (-0.00%)
instructions in affected programs: 36594 -> 36279 (-0.86%)
helped: 46
HURT: 0
total cycles in shared programs: 117573448 -> 117568518 (-0.00%)
cycles in affected programs: 339114 -> 334184 (-1.45%)
helped: 46
HURT: 0
Ivy Bridge / Haswell / Broadwell / Skylake:
total instructions in shared programs: 7774258 -> 7773999 (-0.00%)
instructions in affected programs: 30874 -> 30615 (-0.84%)
helped: 46
HURT: 0
total cycles in shared programs: 65739190 -> 65734530 (-0.01%)
cycles in affected programs: 180380 -> 175720 (-2.58%)
helped: 45
HURT: 1
No change on G45 or Ironlake.
I also tried these expressions, but none of them affected any shaders in
shader-db:
(('bcsel', a, 'a@bool', 'b@bool'), ('ior', a, b)),
(('bcsel', a, 'b@bool', False), ('iand', a, b)),
(('bcsel', a, 'b@bool', 'a@bool'), ('iand', a, b)),
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The unit variable can be used uninitialized.
Fixes: 24e77cb09 ("tgsi: handle indirect sampler arrays. (v2)")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The number of channels must be 4 for all RGBA components.
Fixes: 22d129601 ("tgsi: add support for image operations to tgsi_exec. (v2.1)")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
It was kind of overloaded, returning two different things. Now get
the index of the shadow reference src register with a new
tgsi_util_get_shadow_ref_src_index() function.
To verify the new code, I added some temp/debug code which looped
over all TGSI_TEXTURE_x values, calling the old function and new and
checking that the returned indexes matched.
Also tested piglit "shadow" tests with softpipe/llvmpipe.
No testing of ilo and radeonsi changes.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Should fix the assertion in piglit
spec@arb_gpu_shader5@texturegather@fs-r-none-shadow-2d when the
TXQ instruction specifies a 2D target but the sampler view was
declared as SHADOW2D.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
This fixes a null pointer dereference during the register allocation pass,
if a function had arguments.
Functions arguments get a definition from the function itself, a definition
which is therefore not linked to any instruction. If a value ends up having
a definition but no linked instruction, the register allocation pass doesn't
need to consider whether that value is generated by an instruction that
can only handle "short" registers (on nv50).
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr>
The extension is identical to GL_OES_copy_image. But dEQP has tests that
want the EXT variant.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We require the full ARB_gpu_shader5 for now, but in the future some
other CAP could get exposed to indicate that only the multisample-related
behavior of ARB_gpu_shader5 is available.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Instead of removing every instruction in add_insts_from_block(), just
move the instruction to its scheduled location. This is a step towards
doing both bottom-up and top-down scheduling without conflicts.
Note that this patch changes cycle counts for programs because it begins
including control flow instructions in the estimates.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
I think when this code was written, basic blocks were always ended by a
control flow instruction or an end-of-thread message. That's no longer
the case, and removing this restriction actually helps things:
instructions in affected programs: 7267 -> 7244 (-0.32%)
helped: 4
total cycles in shared programs: 66559580 -> 66431900 (-0.19%)
cycles in affected programs: 28310152 -> 28182472 (-0.45%)
helped: 9577
HURT: 879
GAINED: 2
The addition of the is_control_flow() checks is not a functional change,
since the add_insts_from_block() does not put them in the list of
instructions to schedule. I plan to change this in a later patch.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Missing this causes an assertion failure in the scheduler with the next
patch.
Additionally, this gives cmod propagation enough information to optimize
code better.
total instructions in shared programs: 7112991 -> 7112852 (-0.00%)
instructions in affected programs: 25704 -> 25565 (-0.54%)
helped: 139
total cycles in shared programs: 64812898 -> 64810674 (-0.00%)
cycles in affected programs: 127224 -> 125000 (-1.75%)
helped: 139
Acked-by: Francisco Jerez <currojerez@riseup.net>
This reverts commit d0e1d6b7e2.
The change in the vec4 code is a mistake -- there's never an
FS_OPCODE_FB_WRITE in vec4 code.
The change in the fs code had the (harmless) effect of not recognizing
an FB_WRITE as a scheduling barrier even if it was marked EOT --
harmless because the scheduler marked the last instruction of a block as
a barrier, something I'm changing in the following patches.
This will be reimplemented later in the series.
All of these were simply code for "architecture register file" (and in
the case of destinations, "not the null register").
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
These printed the cycle count the last basic block (sched.time is set
per basic block!). We have accurate, full program, data printed
elsewhere.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Failed to update state tracker with new buffer interface.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This enables in shader defined transform feedback mode even if the
only place xfb_stride is defined is on the global out.
We don't worry about xfb_buffer since Issue 22 c) in the spec says:
"If the shader has an "xfb_buffer" qualifier identifying a buffer,
but doesn't declare "xfb_offset" on anything associated with it,
what happens?
...
variables not qualified with "xfb_offset" are not captured, which
makes the associated "xfb_buffer" qualifier irrelevant."
Reviewed-by: Dave Airlie <airlied@redhat.com>
When we move to the next buffer we need to reset the stream
so that we don't generate an error message about streams not
matching.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This moves the check until after we have done the stride
calculation and applies it to the xfb_* qualifiers.
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_enhanced_layous spec:
"It is a compile-time or link-time error to have any *xfb_offset*
that overflows *xfb_stride*, whether stated on declarations before
or after the *xfb_stride*, or in different compilation units.
...
When no *xfb_stride* is specified for a buffer, the stride of a
buffer will be the smallest needed to hold the variable placed at
the highest offset, including any required padding."
Reviewed-by: Dave Airlie <airlied@redhat.com>
Here we use the built-in validation in
ast_layout_expression::process_qualifier_constant() to check for mismatching
global out strides on buffers in a single shader.
From the ARB_enhanced_layouts spec:
"While *xfb_stride* can be declared multiple times for the same buffer,
it is a compile-time or link-time error to have different values
specified for the stride for the same buffer."
For intrastage validation a new helper link_xfb_stride_layout_qualifiers()
is created. We also take this opportunity to make sure stride is at least
a multiple of 4, we will validate doubles at a later stage.
From the ARB_enhanced_layouts spec:
"If the buffer is capturing any double-typed outputs, the stride must
be a multiple of 8, otherwise it must be a multiple of 4, or a
compile-time or link-time error results."
Finally we update store_tfeedback_info() to apply the strides to
LinkedTransformFeedback and update the buffers bitmask to mark any global
buffers with a stride as active. For example a shader with:
layout (xfb_buffer = 0, xfb_offset = 0) out vec4 gs_fs;
layout (xfb_buffer = 1, xfb_stride = 64) out;
Is expected to have a buffer bound to both 0 and 1.
From the ARB_enhanced_layouts spec:
"A binding point requires a bound buffer object if and only if its
associated stride in the program object used for transform feedback
primitive capture is non-zero."
Reviewed-by: Dave Airlie <airlied@redhat.com>
This will be used in a following patch to implement interface
query support for TRANSFORM_FEEDBACK_BUFFER.
Reviewed-by: Dave Airlie <airlied@redhat.com>
