- Dec 22, 2017
-
-
Andres Gomez authored
Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
Signed-off-by: Andres Gomez <agomez@igalia.com>
-
- Dec 20, 2017
-
-
Andres Gomez authored
extra: The commit references a previous commit in which the changes should have been included but, as clarified by the developer, it is not needed for stable. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
extra: The commit just references a fix for an additional change in its v2. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
fixes: This commit addressed earlier commit d1c9f30d which did not land in branch. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
stable: 17.3 nominations only. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
stable: This commit addressed earlier commit ead0dfe3 which did not land in branch. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
64-bit pull loads are implemented by emitting 2 separate 32-bit pull load messages, where the second message loads from an offset at +16B. That addition of 16B to the original offset should not alter the original offset register used as source for the pull load instruction though, since the compiler might use that same offset register in other instructions (for example, for other pull loads in the shader code that take that same offset as reference). If the pull load is 32-bit then we only need to emit one message and we don't need to do offset calculations, but in that case the optimizer should be able to drop the redundant MOV. Fixes the following test on Haswell: KHR-GL45.gpu_shader_fp64.fp64.max_uniform_components Reviewed-by: Matt Turner <mattst88@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103007 (cherry picked from commit 8620f7eb)
-
We did not set the layer correctly for the dst, as we would keep using the base layer. Same for the source image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102710 CC: <mesa-stable@lists.freedesktop.org> Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit b42e106d)
-
This function is only used in two places: 1. VMware driver, but only for HUD reporting 2. st/nine state tracker, used for texture memory accounting Fixes: a69efa94 ("util: add new util_resource_size() function in u_resource.[ch]") Reviewed-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit dde8309c)
-
The docs are not very concise in what this really does, however both Alex Deucher and Nicolai Hähnle suggested this only really affects instructions using the CLAMP output modifier, and I've confirmed that with the newly changed piglit isinf_and_isnan test. So, with this bit set, if an instruction has the CLAMP modifier bit (which clamps to [0,1]) set, then NaNs will be converted to zero, otherwise the result will be NaN. D3D10 would require this, glsl doesn't have modifiers (with mesa clamp(x,0,1) would get converted to such a modifier) coupled with a whatever-floats-your-boat specified NaN behavior, but the clamp behavior should probably always be used (this also matches what a decomposition into min(1.0, max(x, 0.0)) would do, if min/max also adhere to the ieee spec of picking the non-nan result). Some apps may in fact rely on this, as this prevents misrenderings in This War of Mine since using ieee muls (ce7a045f), without having to use clamped rcp opcode, which would also fix this bug there. radeonsi also seems to set this bit nowadays if I see that righ (albeit the llvm amdgpu code comment now says "Make clamp modifier on NaN input returns 0" instead of "Do not clamp NAN to 0" since it was changed, which also looks a bit misleading). v2: set it in all shader stages. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103544 Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 38350097)
-
I believe this is the safe thing to do, especially ever since the driver actually generates NaNs for muls too. The ISA docs are not very helpful here, however the dx10 versions will pick a non-nan result over a NaN one (this is also the ieee754 behavior), whereas the non-dx10 ones will pick the NaN (verified by newly changed piglit isinf-and-isnan test). Other "modern" drivers will most likely do the same. This was shown to make some difference for bug 103544, albeit it is not required to fix it. Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit aab0bfc6)
-
We use _mesa_warning() everywhere else in this code. Change requested by Rick Irons of Mathworks. CC: <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 7a460638)
-
There is no chain, so checking the length ends with a SEGFAULT. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103579 Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit b926da24) [Andres Gomez: 16 bits types and vtn_assert/fail not yet in 17.2] Signed-off-by: Andres Gomez <agomez@igalia.com> Conflicts: src/compiler/spirv/vtn_variables.c
-
VCE processing IBs starts from session and task info at first level, other commands processed subsequently. The task info for destroy is embedded to destroy command, resulting that feedback command is not properly procoessed. This is causing kernel spin VM fault messages on Polaris and Vega10 card when running ends at encode application. The fix is also verified on VCE physical mode card. Signed-off-by: Leo Liu <leo.liu@amd.com> Cc: mesa-stable@lists.freedesktop.org Acked-by: Christian König <christian.koenig@amd.com> (cherry picked from commit 6d74cb25)
-
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 513d7ffa) (cherry picked from commit 60ed1a07) Squashed with: util: scons: wire up the sha1 test Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Andres Gomez <agomez@igalia.com> (cherry picked from commit 5d03a686) (cherry picked from commit 455ff758)
-
(cherry picked from commit 6a353479) Squashed with: util: Use preprocessor correctly Fixes: 6a353479 ("util: Assume little endian in the absence of platform-specific handling") (cherry picked from commit b8cbad62) Squashed with: util: Just give up and define PIPE_ARCH_LITTLE_ENDIAN on MSVC MSVC doesn't support #warning?! Getting really tired of this. (cherry picked from commit 67676125) Squashed with: util: Also include endian.h on cygwin If u_endian.h can't determine the endianess, the default behaviour in sha1.c is to build for big-endian Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 2c62ccb1)
-
- Dec 14, 2017
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
- Dec 08, 2017
-
-
>From GLSL 4.5 spec, section "7.1 Built-In Language Variables", page 130 of the PDF states: "If multiple shaders using members of a built-in block belonging to the same interface are linked together in the same program, they must all redeclare the built-in block in the same way, as described in section 4.3.9 “Interface Blocks” for interface-block matching, or a link-time error will result." Fixes: * GL45-CTS.CommonBugs.CommonBug_PerVertexValidation v2 (Neil Roberts): Explicitly look for gl_PerVertex in the symbol tables instead of waiting to find a variable in the interface. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102677 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Eduardo Lima Mitev <elima@igalia.com> Signed-off-by: Neil Roberts <nroberts@igalia.com> (cherry picked from commit f9de7f55)
-
This effectively factorizes a couple of similar routines. v2 (Neil Roberts): Non-trivial rebase on master Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Eduardo Lima Mitev <elima@igalia.com> Signed-off-by: Neil Roberts <nroberts@igalia.com> (cherry picked from commit f5fe99ac)
-
Some symbols gathered in the symbols table during parsing are needed later for the compile and link stages, so they are moved along the process. Currently, only functions and non-temporary variables are copied between symbol tables. However, the built-in gl_PerVertex interface blocks are also needed during the linking stage (the last step), to match re-declared blocks of inter-stage shaders. This patch adds a new utility function that will factorize current code that copies functions and variables between two symbol tables, and in addition will copy explicitly declared gl_PerVertex blocks too. The function will be used in a subsequent patch. v2 (Neil Roberts): Allow the src symbol table to be NULL and explicitly copy the gl_PerVertex symbols in case they are not referenced in the exec_list. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Eduardo Lima Mitev <elima@igalia.com> Signed-off-by: Neil Roberts <nroberts@igalia.com> (cherry picked from commit 4c62a270)
-
The dynamic index of a vector (not array!) is lowered to a sequence of conditional assignments. However, the interpolate_at_* expressions require that the interpolant is an l-value of a shader input. So instead of doing conditional assignments of parts of the shader input and then interpolating that (which is nonsensical), we interpolate the entire shader input and then do conditional assignments of the interpolated result. Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com> (cherry picked from commit ca63a5ed)
-
The intended rule has been clarified in GLSL 4.60, Section 8.13.2 (Interpolation Functions): "For all of the interpolation functions, interpolant must be an l-value from an in declaration; this can include a variable, a block or structure member, an array element, or some combination of these. Component selection operators (e.g., .xy) may be used when specifying interpolant." For members of interface blocks, var->data.must_be_shader_input must be determined on-the-fly after lowering interface blocks, since we don't want to disable varying packing for an entire block just because one input in it is used in interpolateAt*. v2: keep setting must_be_shader_input in ast_function (Ian) v3: follow the relaxed rule of GLSL 4.60 v4: only apply the relaxed rules to desktop GL (the ES WG decided that the relaxed rules may apply in a future version but not retroactively; see also dEQP-GLES31.functional.shaders.multisample_interpolation.interpolate_at_centroid.negative.*) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101378 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1) Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com> (cherry picked from commit 4f42450b)
-
GLSL shaders can access the normal scale factor with the built-in gl_NormalScale. Mesa's modelspace lighting optimization uses a different normal scale factor than defined in the spec. We have to take care not to use this factor for gl_NormalScale. Mesa already defines two seperate states: state.normalScale and state.internal.normalScale. The first is used by the glsl compiler while the later is used by the fixed function T&L pipeline. Previously the only difference was some component swizzling. With this commit state.normalScale always uses the normal scale factor for eyespace lighting. Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit c3ee464d)
-
spotExponent and spotCosCutoff were swapped in the gl_builtin_uniform_element struct. Now the order matches across gl_builtin_uniform_element, glsl_struct_field and the spec. Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 9bdb5457)
-
We failed to take the start into account for how many vertices to draw in this round, so we would end up decrementing count below 0, which as an unsigned number meant we would loop until the CLs soon ran out of space. When I wrote the code I was thinking about how to use the previously emitted shader state (no index bias baked into the elements) by emitting up to 65535 and then only re-emitting with bias for the second wround, but that doesn't work if the start is over 65535. Instead, just delay emitting shader state until we get into the drawarrays GFXH-515 loop and always bake the bias in when we're doing the workaround. (cherry picked from commit 84ab48c1)
-
The picture_id was assumed to be a frame number so in 0-31. But the vaapi client gstreamer-vaapi uses the surfaces handles as identifier which are unsigned int. This bug can happen when using a lot of vaapi surfaces within the same process. Indeed Mesa/st/va increments a counter for the surface ID: mesa/util/u_handle_table.c::handle_table_add which starts from 0 and incremented by 1 at each call. So creating more than 32 surfaces was a problem. The following bug contains a test that reproduces the problem by running a couple of vaapih264enc in the same process. The above also explains why there was no pb when running them in separated processes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102006 Signed-off-by: Julien Isorce <jisorce@oblong.com> Tested-by: Tomas Rataj <rataj28@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-and-tested-by: Boyuan Zhang <Boyuan.Zhang@amd.com> (cherry picked from commit 91d93aa6)
-
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102552 v2: Patch cleanup proposed by Nicolai Hähnle. * deleted changes in si_translate_texformat. Cc: Nicolai Hähnle <nhaehnle@gmail.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 74d24564)
-
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103909 Signed-off-by: Vinson Lee <vlee@freedesktop.org> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (cherry picked from commit 8c1e4b1a) [Emil Velikov: resolve trivial conflicts] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Conflicts: configure.ac meson.build src/intel/vulkan/anv_allocator.c
-
64-bit operations on Atom parts have additional restrictions over their big-core counterparts (validated by later patches). Specifically, the restriction that "Source and Destination horizontal stride must be aligned to the same qword" is violated by most shift operations since NIR uses a 32-bit value as the shift count argument, and this causes instructions like shl(8) g19<1>Q g5<4,4,1>Q g23<4,4,1>UD where src1 has a 32-bit stride, but the dest and src0 have a 64-bit stride. This caused ~4 pixels in the ARB_shader_ballot piglit test fs-readInvocation-uint.shader_test to be incorrect. Unfortunately no ARB_gpu_shader_int64 test hit this case because they operate on uniforms, and their scalar regions are an exception to the restriction. We work around this by effectively unpacking the shift count, so that we can read it with a 64-bit stride in the shift instruction. Unfortunately the unpack (a MOV with a dst stride of 2) is a partial write, and cannot be copy-propagated or CSE'd. Bugzilla: https://bugs.freedesktop.org/101984 (cherry picked from commit b541945c)
-
When creating a context without SetPixelFormat() don't blindly take the pixel format reported by GDI. Instead, look for our own closest pixel format. Minor clean-ups added by Brian Paul. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103412 Reviewed-by: Brian Paul <brianp@vmware.com> Tested-by: Brian Paul <brianp@vmware.com> (cherry picked from commit bf41b2b2)
-
This patch is mostly a patch done by Ilia Mirkin. It fixes KHR-GL45.enhanced_layouts.varying_structure_locations. v2: fix locations for TCS/TES/GS inputs and outputs (Ilia) CC: Ilia Mirkin <imirkin@alum.mit.edu> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103098 Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com> (cherry picked from commit d5a64110)
-
Swr caches fb contents in tiles. Those tiles are stored on a per-context basis. When switching contexts that share resources we need to make sure that the tiles of the old context are being stored and the tiles of the new context are being invalidated (marked as invalid, hence contents need to be reloaded). The context does not get any dirty bits to identify this case. This has to be, then, coordinated by the resources that are being shared between the contexts. Add a "curr_pipe" hook in swr_resource that will allow us to identify a MakeCurrent of the above form during swr_update_derived(). At that time, we invalidate the tiles of the new context. The old context, will need to have already store its tiles by that time, which happens during glFlush(). glFlush() is being called at the beginning of MakeCurrent. So, the sequence of operations is: - At the beginning of glXMakeCurrent(), glFlush() will store the tiles of all bound surfaces of the old context. - After the store, a fence will guarantee that the all tile store make it to the surface - During swr_update_derived(), when we validate the new context, we check all resources to see what changed, and if so, we invalidate the current tiles. Fixes rendering problems with CEI/Ensight. Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com> (cherry picked from commit b9aa0fa7) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103732
-
This fixes a crash in: KHR-GL45.enhanced_layouts.xfb_block_stride Fixes: 08225179 "glsl: add helper to process xfb qualifiers during linking" Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 9d53cccc)
-
The flag is on the pipe_resource, not the r600_resource. I don't see an obvious bug related to this, but it could potentially lead to suboptimal placement of some resources. Fixes: a4158743 ("gallium/radeon: add R600_RESOURCE_FLAG_UNMAPPABLE") Reviewed-by: Marek Olšák <marek.olsak@amd.com> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> (cherry picked from commit 5e2962c9)
-
Fixes: 61d7676d "nvc0/ir: add support for 64-bit shift lowering on SM20/SM30" Fixes fs-shift-scalar-by-scalar.shader_test from piglit for the current set-up: uniform int64_t ival -0x7dfcfefbdf6536ff # bit pattern: 0x82030104209ac901 uniform uint64_t uval 0x1400000085010203 uniform int shl 36 uniform int shr 36 uniform int64_t iexpected_shl 0x09ac901000000000 uniform int64_t iexpected_shr -0x7dfcff0 # bit pattern: 0xfffffffff8203010 uniform uint64_t uexpected_shl 0x5010203000000000 uniform uint64_t uexpected_shr 0x0000000001400000 draw rect ortho 12 0 4 4 Signed-off-by: Pierre Moreau <pierre.morrow@free.fr> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 9bee1216)
-
deviceName string is declared, assigned and freed but actually never used in dri3_create_screen() function. Fixes: 2d946015 ("Add DRI3+Present loader") Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (cherry picked from commit d5559292)
-
Fix incomplete check of input params in blorp_surf_convert_to_uncompressed() which can lead to NULL pointer dereferencing. Fixes: 5ae8043f ("intel/blorp: Add an entrypoint for doing bit-for-bit copies") Fixes: f395d0ab ("intel/blorp: Internally expose surf_convert_to_uncompressed") Reviewed-by: Emil Velikov <emli.velikov@collabora.com> Reviewed-by: Andres Gomez <agomez@igalia.com> (cherry picked from commit cdb3eb71) [Emil Velikov: drop non-applicable x/y hunk] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Conflicts: src/intel/blorp/blorp_blit.c
-