- Nov 22, 2019
-
-
Dylan Baker authored
-
Dylan Baker authored
-
- Nov 21, 2019
-
-
Dylan Baker authored
Closes: mesa/mesa#1921
-
From OES_EGL_image_external_essl3 Closes: mesa/mesa#1901 Signed-off-by:
Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Acked-by:
Tapani Pälli <tapani.palli@intel.com>
-
Fixes: 32aba91c (llvmpipe: use ppc64le/ppc64 Large code model for JIT-compiled shaders) Reviewed-by:
Dylan Baker <dylan@pnwbakers.com> Closes: mesa/mesa#2131
-
Fixes: cea39af2 ("freedreno/ir3: Generalize ir3_shader_disasm()") Reviewed-by:
Rob Clark <robdclark@gmail.com> (cherry picked from commit d0f38394)
-
Specifically when we are in non-uniform control flow, as we would need to set the condition for the last instruction. If (for example) a image atomic load stores directly their value on a NIR register, last_inst would be a nop, and would fail when set the condition. Fixes piglit test: spec/glsl-es-3.10/execution/cs-ssbo-atomic-if-else-2.shader_test Fixes: 6281f26f ("v3d: Add support for shader_image_load_store.") v2: (Changes suggested by Eric Anholt) * Cover all sig.ld* signals, not just ldunif and ldtmu, as all of them have the same restriction. * Update comment explaining why we add a MOV in that case * Tweak commit message. v3: * Drop extra set of parens (Eric) * Add missing ld signal to is_ld_signal to fix shader-db regression. Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit b4bc59e3)
-
Fixes dEQP test: dEQP-GLES31.functional.synchronization.inter_call.with_memory_barrier.image_atomic_multiple_interleaved_write_read Fixes piglit test: spec/glsl-es-3.10/execution/cs-image-atomic-if-else.shader_test Fixes: 6281f26f ("v3d: Add support for shader_image_load_store.") Reviewed-by:
Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit d9830551)
-
Eric Engestrom authored
Two files exist in that directory: - vulkan_xlib_randr.h - vulkan_xlib_xrandr.h Both were imported in 205c2715 ("vulkan: Update the XML and headers to 1.1.70") with identical contents (ie. the VK_EXT_acquire_xlib_display extension), but the former was never included anywhere and can't be found upstream [1], while the latter is included in vulkan.h and found upstream. [1] https://github.com/KhronosGroup/Vulkan-Headers/tree/master/include/vulkan Fixes: 205c2715 ("vulkan: Update the XML and headers to 1.1.70") Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Acked-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 344859c3)
-
- Nov 20, 2019
-
-
Dylan Baker authored
-
Dylan Baker authored
-
Dylan Baker authored
-
Faith Ekstrand authored
The bounds checking is actually less safe than just pushing the data. If the bounds checking actually ever kicks in and it's not on the last UBO push range, then the shrinking will cause all subsequent ranges to be pushed to the wrong place in the GRF. One of the behaviors we definitely don't want is for OOB UBO access to result in completely unrelated UBOs returning garbage values. It's safer to just push the UBOs as-requested. If we're really concerned about robustness, we can emit shader code to do bounds checking which should be stupid cheap (a CMP followed by SEL). Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
A security advisory (TALOS-2019-0857/CVE-2019-5068) found that creating shared memory regions with permission mode 0777 could allow any user to access that memory. Several Mesa drivers use shared- memory XImages to implement back buffers for improved performance. This path changes the shmget() calls to use 0600 (user r/w). Tested with legacy Xlib driver and llvmpipe. Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Kristian H. Kristensen <hoegsberg@google.com> (cherry picked from commit 02c3dad0)
-
Danylo Piliaiev authored
Re-emitting 3DSTATE_CC_STATE_POINTERS after emitting 3DSTATE_BLEND_STATE_POINTERS fixes the shadow flickering in SuperTuxCart and Tropico 6 which was seen only on Haswell. The reason for this is unknown and fix was found empirically. The closest mention in PRM is that it should improve performance. From the HSW PRM, volume 2b, page 823 (3DSTATE_BLEND_STATE_POINTERS): "When the BLEND_STATE pointer changes but not the CC_STATE pointer, driver needs to force a CC_STATE pointer change to improve blend performance in pixel backend." Closes: mesa/mesa#1834 Fixes: eca4a654 ("i965: Disable dual source blending when shader doesn't support it on gen8+") Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Danylo Piliaiev <danylo.piliaiev@globallogic.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 6f17fe06)
-
Large programs, e.g. gnome-shell and firefox, may tax the addressability of the Medium code model once a (potentially unbounded) number of dynamically generated JIT-compiled shader programs are linked in and relocated. Yet the default code model as of LLVM 8 is Medium or even Small. The cost of changing from Medium to Large is negligible: - an additional 8-byte pointer stored immediately before the shader entrypoint; - change an add-immediate (addis) instruction to a load (ld). Testing with WebGL Conformance (https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html) yields clean runs with this change (and crashes without it). Testing with glxgears shows no detectable performance difference. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1753327, 1753789, 1543572, 1747110, and 1582226 Closes: mesa/mesa#223 Co-authored by: Nemanja Ivanovic <nemanjai@ca.ibm.com>, Tom Stellard <tstellar@redhat.com> CC: mesa-stable@lists.freedesktop.org Signed-off-by:
Ben Crocker <bcrocker@redhat.com> (cherry picked from commit 9c3be6d2) Conflicts resolved Dylan (PIPE_ARCH -> UTIL_ARCH rename)
-
Pierre-Eric Pelloux-Prayer authored
Use unsigned values otherwise signed extension will produce a 64 bits value where the 32 left-most bits are 1. Fixes: 2afeed30 ("radeonsi: tell the shader disk cache what IR is used")
-
Pierre-Eric Pelloux-Prayer authored
Until 8bef4df1 the IR (TGSI or NIR) was used in disk_cache driver_flags. This commit restores this features to avoid crashing when switching from one IR to the other. As radeonsi's default is TGSI, I used "driver_flags & 0x8000000 = 0" for TGSI to keep the same driver_flags. Fixes: 8bef4df1 ("radeonsi: add si_debug_options for convenient adding/removing of options") Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com>
-
Pierre-Eric Pelloux-Prayer authored
Disable sdma on gfx10 until all timeouts bugs are fixed. See: mesa/mesa#1907 https://bugs.freedesktop.org/show_bug.cgi?id=111481 Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Marek Olšák authored
radeonsi doesn't use the format and internal shaders don't set it. Reviewed-By:
Timur Kristóf <timur.kristof@gmail.com> (cherry picked from commit f704fb7f) Closes: mesa/mesa#2112
-
Marek Olšák authored
This caused a failure in NIR validation. Reviewed-by:
Connor Abbott <cwabbott0@gmail.com> Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 3906fce8)
-
After the discussion in https://github.com/KhronosGroup/OpenGL-API/issues/45 the section 8.17 (texture completeness) of the OpenGL 4.6 core profile was changed to explicitly say that multisample texture completeness ignores filter state of the texture. "Using the preceding definitions, a texture is complete unless any of the following conditions hold true: ... - The minification filter requires a mipmap (is neither NEAREST nor LINEAR), the texture is not multisample, and the texture is not mipmap complete. - The texture is not multisample; either the magnification filter is not NEAREST, or the minification filter is neither NEAREST nor NEAREST_- MIPMAP_NEAREST; and any of – The internal format of the texture is integer (see table 8.12). – The internal format is STENCIL_INDEX. – The internal format is DEPTH_STENCIL, and the value of DEPTH_- STENCIL_TEXTURE_MODE for the texture is STENCIL_INDEX." Signed-off-by:
Danylo Piliaiev <danylo.piliaiev@globallogic.com> Signed-off-by:
Illia Iorin <illia.iorin@globallogic.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 6b672e34)
-
This prevents some additional optimizations that would change the original result. This includes things like (b < a && b < c) => b < min(a, c) and !(a < b) => b >= a. Both of these optimizations were specifically observed in the piglit tests added in piglit!160. This was discovered while investigating mesa/mesa#1958 . However, the problem in that issue was Chrome or Angle is replacing calls to isnan() with some stuff that we (correctly) optimize to false. If they had left the calls to isnan() alone, everything would have just worked. No shader-db changes on any Intel platform. I also tried marking the comparison generated by the isnan() function precise. The precise marker "infects" every computation involved in calculating the parameter to the isnan() function, and this severely hurt all of the (few) shaders in shader-db that use isnan(). I also considered adding a new ir_unop_isnan opcode that would implement the functionality. During GLSL IR-to-NIR translation, the resulting comparison operation would be marked exact (and the samething would need to happen in SPIR-V translation). This approach taken by this patch seemed easier, but we may want to do the ir_unop_isnan thing anyway. Fixes: d55835b8 ("nir/algebraic: Add optimizations for "a == a && a CMP b"") Reviewed-by:
Matt Turner <mattst88@gmail.com> Reviewed-by:
Connor Abbott <cwabbott0@gmail.com> (cherry picked from commit 9be4a422)
-
Reviewed-by:
Matt Turner <mattst88@gmail.com> Reviewed-by:
Connor Abbott <cwabbott0@gmail.com> (cherry picked from commit ea19f2fb)
-
On ICL we have the src1 restriction which is applied through fix_byte_src() and potentially changes the type of the operands from 8 to 32 bits. When this change happens, we fall into the "else if (bit_size < 32)" case and miscompute src_type because it takes into consideration bit_size (8) instead of the adjusted size of temp_op (32). This results in the shader reading unused memory, giving us mostly failures, but occasional passes due to whatever was already in the registers we were reading. This commit fixes a lot of dEQP subgroup i8vec2 tests on ICL, such as: dEQP-VK.subgroups.arithmetic.compute.subgroupadd_i8vec2 This can also be verified by simply changing fix_byte_src() to apply on all platforms. Fixes: 5847de6e ("intel/compiler: don't use byte operands for src1 on ICL") Reviewed-by:
Ivan Briano <ivan.briano@intel.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> (cherry picked from commit eb635216)
-
Marek Olšák authored
They use the "sample" keyword as a variable name. Cc: 19.2 19.3 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> (cherry picked from commit e00791c5)
-
We seem to have forgotten about the semaphore in the acquireNextImageInfo. v2: Signal semaphore/fence regardless of presentation status (Jason) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit edc6606d)
-
This doesn't seem to fix anything because those destroy() calls happen right before the command buffer object & its list of batch_bo is also destroyed. Still looks a bit cleaner. v2: Found a second occurence Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (v2) Fixes: 26ba0ad5 ("vk: Re-name command buffer implementation files") Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit 935f8f0e)
-
We always close the in_fence at the end the anv_cmd_buffer_execbuf() so when we take it from the semaphore, let's not forget to invalidate it. Note that the code leaks the fence_in if we get any error before reaching the close(). Let's fix that in another patch or better, rewrite the whole thing! v2: drop redundant fd = -1 (Jason) v3: Update commit message (Jason) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 048f0690)
-
Dylan Baker authored
-
- Nov 13, 2019
-
-
Eric Engestrom authored
When the X11 or Haiku platforms were compiled in, they would bypass the `_EGL_NATIVE_PLATFORM` fallback by always returning themselves instead. Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 86d3a346)
-
Caio Oliveira authored
The stage specific fields of shader_info are in an union. We've likely been lucky that this value was either overwritten or ignored by other stages. The recent change in shader_info layout in commit 84a1a257 ("compiler: pack shader_info from 160 bytes to 96 bytes") made this issue visible. Fixes: cf225706 ("nir/spirv: Set a default number of invocations for geometry shaders") Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 087ecd9c)
-
This fix wrong color when playing video under Android + virgl configuration. Fixes: 2decad49 ("gallium/dri2: Support images with multiple planes for modifiers") Reviewed-by:
Eric Engestrom <eric.engestrom@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Lepton Wu <lepton@chromium.org> (cherry picked from commit 5a40e153)
-
Dylan Baker authored
-
Dylan Baker authored
-
Dylan Baker authored
-
The change made in 88d66583 ("mesa: check draw buffer completeness on glClearBufferfi/glClearBufferiv") correctly updated the state prior to checking the framebuffer completeness on glClearBufferiv but not in glClearBufferfi. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Anuj Phogat <anuj.phogat@gmail.com> Fixes: 88d66583 ("mesa: check draw buffer completeness on glClearBufferfi/glClearBufferiv") Closes: mesa/mesa#2072 (cherry picked from commit f93bb903)
-
- Nov 06, 2019
-
-
Dylan Baker authored
-
Dylan Baker authored
-
- Nov 05, 2019
-
-
Dylan Baker authored
Otherwise if glvnd is not installed systemwide, but only in a prefix, it's headers wont be found. This happens because if it's headers are in /usr/include/ then another dependence will provide the necessary -I arguments and compilation will work. Fixes: 035ec7a2 ("meson: Add support for EGL glvnd") Acked-by:
Eric Engestrom <eric@engestrom.ch> (cherry picked from commit 5d085ad0)
-