- Apr 18, 2018
-
-
Juan A. Suárez authored
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
-
Juan A. Suárez authored
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
-
- Apr 17, 2018
-
-
It is present from libva 2.1 (VAAPI 1.1.0 or higher). Signed-off-by: Mark Thompson <sw@jkqxz.net> Reviewed-by: Christian König <christian.koenig@amd.com> (cherry picked from commit 768f1487)
-
- Apr 14, 2018
-
-
LLVM patch level is not included in HAVE_LLVM. Fixes: e6418ab1566d ("meson: build "radv" vulkan driver for radeon hardware") Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Dylan Baker <dylan.c.baker@intel.com> Signed-off-by: Marc Dietrich <marvin24@gmx.de> (cherry picked from commit a2a1b0e7)
-
- Apr 12, 2018
-
-
num_dcc_levels means that DCC is supported, but this doesn't mean that it's enabled by the driver. Instead, we should rely on radv_image_has_dcc(). This fixes some multisample regressions since 0babc8e5 ("radv: fix picking the method for resolve subpass") on Vega. This is because the resolve method changed from HW to FS, but those fails are totally unexpected, so there might some differences between Polaris and Vega here. Fixes: 44fcf587 ("radv: Disable DCC for GENERAL layout and compute transfer dest.") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 9eac4924) [Juan A. Suarez: do not call radv_image_has_dcc(), as it is not defined] Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
-
The source and destination image parameters were swapped. No CTS changes on Polaris10, but I suspect this might fix something. Fixes: 2a04f548 ("radv/meta: select resolve paths") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 0babc8e5)
-
As we sometimes reset them to -1, -1 does not mean that they are not written by the secondary command buffer. Fixes: ad11fc35 "radv: don't emit unneeded vertex state." Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 41fbcc79)
-
The packet can sometimes be skipped, but we still think the change takes effect. This just makes the packet always take effect. Fixes: ad11fc35 "radv: don't emit unneeded vertex state." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105942 Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 74b0b869)
-
Fixes: 03fd6704 ("mesa: Add support for a new override string MESA_GLES_VERSION_OVERRIDE") Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ian Romanick <ian.d.romanick@intel.com> Signed-off-by: Andres Gomez <agomez@igalia.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 7cf39320)
-
v2: - Provide a correct explanation on the envvars documentation (Ian). - Provide a more correct explanation on the function comments (Andres). v3: - Homogenize documentation and inline comments (Emil). - Correct a typo (Emil). Fixes: 2599b92e ("mesa: allow forcing >=3.1 compatibility contexts with MESA_GL_VERSION_OVERRIDE") Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ian Romanick <ian.d.romanick@intel.com> Cc: Eric Engestrom <eric.engestrom@imgtec.com> Cc: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 806ab42c)
-
This way we won't fail when validating just because we may have a non overriden core version that is lower than the requested one, even when the compat version is high enough. For example, running glcts from VK-GL-CTS with i965, this will succeed: $ MESA_GL_VERSION_OVERRIDE=4.6 ./glcts --deqp-case=KHR-GL46.info.vendor While, this will fail: $ MESA_GL_VERSION_OVERRIDE=4.6COMPAT ./glcts --deqp-case=KHR-GL46.info.vendor Fixes: 464c56d3 ("dri_util: Use _mesa_override_gl_version_contextless") Cc: Ian Romanick <ian.d.romanick@intel.com> Cc: Tapani Pälli <tapani.palli@intel.com> Cc: Marek Olšák <marek.olsak@amd.com> Signed-off-by: Andres Gomez <agomez@igalia.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (cherry picked from commit 044acd35)
-
Which should be relative instead of absolute. Fixes: f7f1b30f ("meson: extend install_megadrivers script to handle symmlinking") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105567 Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Reviewed-and-Tested-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 6ac87c17)
-
Fixes: 0ba909f0 ("meson: build gallium xa state tracker") Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 19dbed64)
-
Otherwise we may end up trying to coalesce in a case such as ssa_1 = fadd r1, r2 r3.x = fneg(r2); r3 = vec4(ssa_1, ssa_1.y, ...) and that would cause us to move the writes to r3 from the vec to the fadd which would re-order them with respect to the write from the fneg. In order to solve this, we just don't coalesce if the destination of the vec is not SSA. We could try to get clever and still coalesce if there are no writes to the destination of the vec between the vec and the ALU source. However, since registers only come from phi webs and indirects, the chances of having a vec with a register destination that is actually coalescable into its source is very slim. Shader-db results on Haswell: total instructions in shared programs: 13657906 -> 13659101 (<.01%) instructions in affected programs: 149291 -> 150486 (0.80%) helped: 0 HURT: 592 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105440 Fixes: 2458ea95 "nir/lower_vec_to_movs: Coalesce movs on-the-fly when possible" Reported-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com> Tested-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 800df942)
-
This fixes a bug in radeonsi where LLVM cannot handle the case where a break exists but its not the last instruction in the block. LLVM would fail with: Terminator found in the middle of a basic block! LLVM ERROR: Broken function found, compilation aborted! Fixes: 96fe8834 "glsl_to_tgsi: do fewer optimizations with GLSLOptimizeConservatively" Reviewed-by: Matt Turner <mattst88@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105317 (cherry picked from commit b42633db)
-
Without this the return value will never get set to -1. This was first added in 49866c8f and copied in 2b396eee. Fixes: 2b396eee "gallium/pb_cache: add a copy of cache bufmgr independent of pb_manager" Reviewed-by: Marek Olšák <marek.olsak@amd.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102342 (cherry picked from commit 7e9b7ec0)
-
When allocating a buffer for DRI2, set the modifier to INVALID to inform the backend that we have no supplied modifiers and it should do its own thing. The missed initialisation forced linear, even if the implementation had made other decisions. This resulted in VC4 DRI2 clients failing with: Modifier 0x0 vs. tiling (0x700000000000001) mismatch Signed-off-by: Daniel Stone <daniels@collabora.com> Reported-by: Andreas Müller <schnitzeltony@gmail.com> Reviewed-by: Eric Anholt <eric@anholt.net> Fixes: 3f851317 ("gallium/winsys/drm: introduce modifier field to winsys_handle") (cherry picked from commit 4cbecb61)
-
Otherwise, any indirect push constant access results in an assertion failure when we start digging through the channel_sizes array. This fixes dEQP-VK.pipeline.push_constant.graphics_pipeline.dynamic_index_vert on Haswell. It should be a harmless no-op for GL since indirect push constants aren't used there. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Fixes: e69e5c70 "i965/vec4: load dvec3/4 uniforms first in the..." (cherry picked from commit 2b977989)
-
On GFX9 whether the buffer size is interpreted as elements or bytes depends on whether IDXEN is enabled in the instruction. If the index is a constant zero, LLVM optimizes IDXEN to 0. Now the size in elements is interpreted in bytes which of course results in out of bounds accesses. The correct fix is most likely to disable the LLVM optimization, but we need something to work with LLVM <= 6.0. radeonsi does the max between stride and element count on the CPU but that results in the size intrinsics returning the wrong size for the buffer. This would cause CTS errors for radv. v2: Also include the store changes. Fixes: e38685cc 'Revert "radv: disable support for VEGA for now."' Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 4503ff76) [Juan A. Suarez: partially backported from 908a0cd1dbe5, a backport for 17.3 stable branch; resolved trivial conflicts] Conflicts: src/amd/common/ac_nir_to_llvm.c src/amd/vulkan/radv_nir_to_llvm.c
-
Otherwise meson won't read the VERSION file and won't set a version. That means that pkg-config files will have version unset as well. Fixes: 3e9533d9 ("meson: Add script to use VERSION file for getting version") Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (cherry picked from commit bc2fdb97)
-
I assume this was implemented in a previous version of that commit, but was removed in the version that actually landed. Fixes: 8430af5e "Add support for swrast to the DRM EGL platform" Cc: Giovanni Campagna <gcampagna@src.gnome.org> Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 431a1d12)
-
When an if nesting inside anouther if is optimised away we can end up with a loop terminator and following block that looks like this: if ssa_596 { block block_5: /* preds: block_4 */ vec1 32 ssa_601 = load_const (0xffffffff /* -nan */) break /* succs: block_8 */ } else { block block_6: /* preds: block_4 */ /* succs: block_7 */ } block block_7: /* preds: block_6 */ vec1 32 ssa_602 = phi block_6: ssa_552 vec1 32 ssa_603 = phi block_6: ssa_553 vec1 32 ssa_604 = iadd ssa_551, ssa_66 The problem is the phis. Loop unrolling expects the last block in the loop to be empty once we splice the instructions in the last block into the continue branch. The problem is we cant move phis so here we lower the phis to regs when preparing the loop for unrolling. As it could be possible to have multiple additional blocks/ifs following the terminator we just convert all phis at the top level of the loop body for simplicity. We also add some comments to loop_prepare_for_unroll() while we are here. Fixes: 51daccb2 "nir: add a loop unrolling pass" Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105670 (cherry picked from commit 629ee690)
-
Just checking for 2 jumps is not enough to be sure we can do a complex loop unroll. We need to make sure we also have also found 2 loop terminators. Without this we were attempting to unroll a loop where the second jump was nested inside multiple ifs which loop analysis is unable to detect as a terminator. We ended up splicing out the first terminator but failed to actually unroll the loop, this resulted in the creation of a possible infinite loop. Fixes: 646621c6 "glsl: make loop unrolling more like the nir unrolling path" Tested-by: Gert Wollny <gw.fossdev@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105670 (cherry picked from commit 56b86739) Squashed with: glsl: remove unreachable assert() Earlier commit enforced that we'll bail out if the number of terminators is different than 2. With that in mind, the assert() will never trigger. Fixes: 56b86739 ("glsl: fix infinite loop caused by bug in loop unrolling pass") Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 8eceac9d)
-
When registring configurations to the kernel for the first time, we run into an issue where the id number is not properly set (we're using the wrong variable). As a result when trying to use that id later on, we get an error. This issue manifest itself the first time you use frameretrace after reboot, subsequent runs are fine. Fixes: 27ee83ea ("i965: perf: add support for userspace configurations") Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 1603ce19) [Juan A. Suarez: resolve trivial conflicts] Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com> Conflicts: src/mesa/drivers/dri/i965/brw_performance_query.c
-
Juan A. Suárez authored
fixes: The commit fixes earlier commits 83d4a5d5, b2f2236d and c62cf1f1 which did not land in branch. Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
-
v2: Add Fixes tag. (Lionel) Fixes: e50d4807 ("anv: Compile TCS/TES shaders.") Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (cherry picked from commit 318073ce)
-
Juan A. Suárez authored
fixes: The commit requieres earlier commits 639c4f2b and 2cfba40e which did not land in branch. Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
-
Juan A. Suárez authored
fixes: The commit fixes earlier commit 1c57a6da which did not land in branch. Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
-
These helpers insert the basic block in the same order as they appear in NIR making it easier to follow LLVM IR dumps. The helpers also insert more useful labels onto the blocks. TGSI use the line number of the corresponding opcode in the TGSI dump as the label id, here we use the corresponding block index from NIR. Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 99cdc019)
-
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 6e1a1428)
-
These have been ported over from radeonsi. Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 42627dab) [Juan A. Suarez: resolve trivial conflicts] Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com> Conflicts: src/amd/common/ac_llvm_build.c src/amd/common/ac_llvm_build.h
-
Meson's compiler.has_header is completely useless, it only checks that a header exists, not whether it's usable. This creates problems if a header contains a conditional #error declaration, like so: > #if __x86_64__ > # error "Doesn't work with x86_64!" > #endif Compiler.has_header will return true in this case, even when compiling for x86_64. This is useless. Instead, we'll do a compile check so that any #error declarations will be treated as errors, and compilation will work. Fixes compilation on x32 architecture. Gentoo Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=649746 meson bug: https://github.com/mesonbuild/meson/issues/2246 Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Acked-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (cherry picked from commit 8247a308) [Juan A. Suarez: resolve trivial conflicts] Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com> Conflicts: meson.build
-
commit 03dd9a88 introduced per surface queues, but the display_sync for swrast_commit_backbuffer remained on the old queue. This is likely to break when dispatching the correct queue at the top of function (which can't dispatch the sync callback we're waiting for). The easiest known reproduction case is running weston-subsurfaces under weston --use-pixman Signed-off-by: Derek Foreman <derekf@osg.samsung.com> Reviewed-by: Daniel Stone <daniels@collabora.com> (cherry picked from commit aa18a635)
-
When creating a image from a texture, the image's dri_format is set to the first plane's format, and used to look up for the fourcc. e.g. for FOURCC_NV12 texture, the dri_format is set to __DRI_IMAGE_FORMAT_R8, we end up with a wrong entry in function intel_lookup_fourcc(): { __DRI_IMAGE_FOURCC_R8, __DRI_IMAGE_COMPONENTS_R, 1, { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 }, } }, instead of the correct one: { __DRI_IMAGE_FOURCC_NV12, __DRI_IMAGE_COMPONENTS_Y_UV, 2, { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 }, { 1, 1, 1, __DRI_IMAGE_FORMAT_GR88, 2 } } }, as a result, a wrong fourcc __DRI_IMAGE_FOURCC_R8 was returned. To fix this bug, the image inherits the texture's planar_format that has the original fourcc; Upon querying, if planar_format is set, return the saved fourcc; Otherwise fall back to the old way. v3: add a bug description and "cc mesa-stable" tag (Jason) remove redundant null pointer check (Tapani) squash 2 patches into one (James) v2: fall back to intel_lookup_fourcc() when planar_format is NULL (Dongwon & Matt Roper) Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Xiong, James <james.xiong@intel.com> Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (cherry picked from commit f23b45dc)
-
Scratch registers are reused every instructions. Since vFace is reused, a new temporary register should be used. Fixes: https://github.com/iXit/Mesa-3D/issues/311 Signed-off-by: Axel Davy <davyaxel0@gmail.com> CC: "17.3 18.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d8998267)
-
The lighting constants were not declared previously, but were accessed with indirect addressing, which is illegal. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105442 Signed-off-by: Axel Davy <davyaxel0@gmail.com> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> CC: "17.3 18.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 39240926)
-
From the SPIR-V spec, OpTypeImage: "Depth is whether or not this image is a depth image. (Note that whether or not depth comparisons are actually done is a property of the sampling opcode, not of this type declaration.)" The sampling opcodes that specify depth comparisons are OpImageSample{Proj}Dref{Explicit,Implicit}Lod, so we should set is_shadow only for these (we were using the deph property of the image until now). v2: - Do the same for OpImageDrefGather. - Set is_shadow to false if the sampling opcode is not one of these (Jason) - Reuse an existing switch statement instead of adding a new one (Jason) Fixes crashes in: dEQP-VK.spirv_assembly.instruction.graphics.image_sampler.depth_property.* Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 41ac0b14)
-
Gen8+ use 48-bit address relocations so need to extend the sign to 64-bit return value. Without it we have higher bits zeroed and missing the negavive values. Haswell and older use 32-bit deltas so are unaffected by this issue. v2: used int32_t fucntion parameter instead of explicit type conversion. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408 Signed-off-by: Sergii Romantsov <sergii.romantsov@globallogic.com> Tested-by: Andriy Khulap <andriy.khulap@globallogic.com> Tested-by: Stuart Young <cefiar@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "18.0 17.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 98b860e3)
-
Buffers can be large, so we probably don't want to make them all 32x bigger. But they can't be rendered to (at least in GL) so we don't need this workaround to prevent page faults on mem<->gmem. Cc: "18.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Rob Clark <robdclark@gmail.com> (cherry picked from commit 2f175bfe)
-
We could alternatively fall back to using "old style" draw's for mem<->gmem (ie. what <= a4xx do) when height is not aligned to 32, but that is somewhat more work (and not really something that could be applied to stable) Cc: "18.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Rob Clark <robdclark@gmail.com> (cherry picked from commit 1866f76f)
-