- Mar 09, 2020
-
-
Eric Engestrom authored
Signed-off-by:
Eric Engestrom <eric@engestrom.ch>
-
Eric Engestrom authored
Signed-off-by:
Eric Engestrom <eric@engestrom.ch>
-
Eric Engestrom authored
Signed-off-by:
Eric Engestrom <eric@engestrom.ch>
-
- Mar 07, 2020
-
-
The client may enable robustBufferAccess2 via either pCreateInfo->pEnabledFeatures or via a chained-in VkPhysicalDeviceFeatures2 struct. We need to parse both. Fixes: 022e5c7e "anv: Implement VK_KHR_get_physical_device_properties2" Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <!3777> (cherry picked from commit 35ca2ad2)
-
Eric Engestrom authored
-
- Mar 06, 2020
-
-
Eric Engestrom authored
Fixes: 86079447 ("scripts: Add a gen_release_notes.py script") Signed-off-by:
Eric Engestrom <eric@engestrom.ch> Reviewed-by:
Dylan Baker <dylan@pnwbakers.com> Tested-by: Marge Bot <!4069> Part-of: <!4069> (cherry picked from commit d7a70fbb)
-
We depend on BLORP to convert the clear color and write it into the clear color buffer for us. However, we weren't bothering to call blorp in the case where the state is ISL_AUX_STATE_CLEAR. This leads to the clear color not getting properly updated if we have back-to-back clears with different clear colors. Technically, we could go out of our way to set the clear color directly from iris in this case but this is a case we're unlikely to see in the wild so let's not bother. This matches what we already do for color surfaces. Cc: mesa-stable@lists.freedesktop.org Reported-by:
Mark Janes <mark.a.janes@intel.com> Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Tested-by: Marge Bot <mesa/mesa!4073> Part-of: <mesa/mesa!4073> (cherry picked from commit 9d07d598)
-
Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Part-of: <mesa/mesa!3717> (cherry picked from commit 9f5f4269)
-
This reverts commit da1c4917. The reduced formula has precision problems on fp16 around 0. Bring back the old formula, but make sure to keep the clamping. Tested-by: Marge Bot <mesa/mesa!4054> Part-of: <mesa/mesa!4054> (cherry picked from commit 9f9432d5)
-
This reverts commit 9807f502. The simplified formula doesn't pass the tanh dEQP tests when we lower to fp16 math. Part-of: <mesa/mesa!4054> (cherry picked from commit 986e92f0)
-
This reverts commit f04d7439. It no longer helps performance and the current vbo implementation is faster anyway. The app that hit this was a CAD program called Spazio3D. It made pretty terrible use of the OpenGL API and we sent them some tips for improvements. I'm assuming they've fixed this by now. Reviewed-by:
Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com> Part-of: <mesa/mesa!4052> (cherry picked from commit df3891e7)
-
This reverts commit 35fc7bdf. Unfortunately mentioned commit introduced a memory leak because `driwindowsMapConfigs` and `createDriMode` functions allocate small memory portions for each element: 21,576 (232 direct, 21,344 indirect) bytes in 1 blocks are definitely lost in loss record 1,411 of 1,414 at 0x483A7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x5D4AA09: createDriMode (dri_common.c:291) by 0x5D4ABF5: driConvertConfigs (dri_common.c:310) by 0x5D58414: dri3_create_screen (dri3_glx.c:945) by 0x5D39829: AllocAndFetchScreenConfigs (glxext.c:815) by 0x5D39C57: __glXInitialize (glxext.c:941) by 0x5D3290A: GetGLXPrivScreenConfig (glxcmds.c:174) by 0x5D34F38: glXQueryExtensionsString (glxcmds.c:1307) by 0x4F83038: glXQueryExtensionsString (in /usr/local/lib/libGL.so.1.7.0) by 0x4F2EA6B: ??? (in /usr/lib/x86_64-linux-gnu/libwaffle-1.so.0.6.0) by 0x4F2A0D7: waffle_display_connect (in /usr/lib/x86_64-linux-gnu/libwaffle-1.so.0.6.0) by 0x498F42A: wfl_checked_display_connect (piglit-util-waffle.h:74) There is one more thing which disallow us to easily fix it are different element sizes for instance: `glx_config_create_list` allocates memory just for `glx_config`, `driwindowsMapConfigs` for `driwindows_config` and `createDriMode` for `__GLXDRIconfigPrivate`. Yes it is possible but size of such fix will be more big and complex than original one. So it make sense only if the malloc overhead really is a big problem there. Acked-by:
Eric Engestrom <eric@engestrom.ch> Signed-off-by:
Andrii Simiklit <andrii.simiklit@globallogic.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3406> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3406> (cherry picked from commit 311c82e1)
-
Fixes a GPU hang in Car Chase. Cc: mesa-stable@lists.freedesktop.org v2: Add comment explaining why (Jason). Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Marge Bot <mesa/mesa!4035> Part-of: <mesa/mesa!4035> (cherry picked from commit 5f139962)
-
Found by inspection, I'm not aware of any bugs caused by this typo. According to Lionel, it seems we only use this to generate masks of available EUs for perfromance queries, and it's only used when we can't query the fused parts of the GPU through DRM_IOCTL_I915_QUERY. So this patch should help for the corner case where the Kernel is too old to support the query ioctl. v2: improve commit message, cc stable (Lionel). Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Part-of: <mesa/mesa!4006> (cherry picked from commit aa78801f)
-
Earlier commit did not take in to account that lists required for rendering and texturing are parsed separately. This commit simply removes formats added to the other list. Fixes: de4eb9a3 ("mesa/st: toggle EXT_texture_norm16 based on format support") Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Tested-by: Marge Bot <mesa/mesa!3961> Part-of: <mesa/mesa!3961> (cherry picked from commit fbd61b3f)
-
Our current GPGPU_WALKER code only supports up to 64 threads. On HSW we could use up to 70 and TGL up to 112, but only if the walker is adjusted so the width does not exceed 64. Work to support this is in progress. Previous to this change, we might try to downgrade to SIMD8 if the SIMD16 shader spilled. Since HSW and TGL have the max number of threads above 64, we would then try to emit an invalid GPGPU walker command. Fixes: 93204506 ("i965/cs: Emit compute shader code and upload programs") Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> (cherry picked from commit cf12faef)
-
The hardware doesn't flush denorms, exactly like fmin/fmax, so we have to do it manually. This doesn't fix anything known. Fixes: d6a07732 ("ac: use llvm.amdgcn.fmed3 intrinsic for nir_op_fmed3") Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Tested-by: Marge Bot <mesa/mesa!3962> Part-of: <mesa/mesa!3962> (cherry picked from commit 9e5d2a73)
-
16-bit med3 is only supported on GFX9+. Fixes dEQP-VK.spirv_assembly.instruction.amd_trinary_minmax.mid3.f16.*. Fixes: d6a07732 ("ac: use llvm.amdgcn.fmed3 intrinsic for nir_op_fmed3") Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!3962> (cherry picked from commit 30ac7336)
-
Lower 64-bit fmed3 because LLVM doesn't expose an intrinsic. Fixes dEQP-VK.spirv_assembly.instruction.amd_trinary_minmax.mid3.f64.*. Fixes: d6a07732 ("ac: use llvm.amdgcn.fmed3 intrinsic for nir_op_fmed3") Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!3962> (cherry picked from commit 50b8c252)
-
Reviewed-by:
Marek Olšák <marek.olsak@amd.com> CC: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Mathias Fröhlich <Mathias.Froehlich@web.de> Tested-by: Marge Bot <mesa/mesa!3958> Part-of: <mesa/mesa!3958> (cherry picked from commit 636656bc)
-
This broke TGSI GS shaders with llvmpipe, it wasn't looking at the right immediates and it should be cast to an integer type. Fixes: 163d5fde (gallium/swr: Enable GL_ARB_gpu_shader5: multiple streams) Reviewed-by:
Krzysztof Raszkowski <krzysztof.raszkowski@intel.com> Acked-by:
Jan Zielinski <jan.zielinski@intel.com> Tested-by: Marge Bot <mesa/mesa!3949> Part-of: <mesa/mesa!3949> (cherry picked from commit 954cf8e8)
-
Closes: mesa/mesa#2556 Fixes: 7f467d4f ("mesa: GL_EXT_texture_norm16 extension plumbing") Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Acked-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Alejandro Piñeiro <apinheiro@igalia.com> Tested-by: Marge Bot <mesa/mesa!3941> Part-of: <mesa/mesa!3941> (cherry picked from commit de4eb9a3)
-
The __DRI_IMAGE_FORMAT_* part wants to be handled for the *101010 type formats as well. Factor out a common function for that task. That again makes the piglit egl_ext_device_base test work again for hardware drivers. v2: Factor out a common function for that task. v3: dri2_pbuffer_visuals -> dri2_pbuffer_visuals Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Fixes: 9acb94b6 "egl: Enable 10bpc EGLConfigs for platform_{device,surfaceless}" Signed-off-by:
Mathias Fröhlich <Mathias.Froehlich@web.de> Part-of: <mesa/mesa!3790> (cherry picked from commit d32c458d)
-
Fixes: 7f467d4f ("mesa: GL_EXT_texture_norm16 extension plumbing") Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!3941> (cherry picked from commit 200a83a9)
-
Fixes: 7f467d4f ("mesa: GL_EXT_texture_norm16 extension plumbing") Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!3941> (cherry picked from commit dc531869)
-
-
Eric Engestrom authored
-
Eric Engestrom authored
-
Eric Engestrom authored
-
Eric Engestrom authored
-
Eric Engestrom authored
-
Eric Engestrom authored
-
Eric Engestrom authored
-
- Feb 25, 2020
-
-
When a resource is written by a compute shader and then used by a non-compute stage we sync on last compute job to guarantee that the resource has been completely written when the next stage reads resources. In the other cases how flushes are done guarantee the serialization of the writes and reads. To reproduce the failure the following tests should be executed in batch as last test don't fail when run isolated: KHR-GLES31.core.shader_image_load_store.basic-allFormats-load-fs KHR-GLES31.core.shader_image_load_store.basic-allFormats-loadStoreComputeStage KHR-GLES31.core.shader_image_load_store.basic-allTargets-load-cs KHR-GLES31.core.shader_image_load_store.advanced-sync-vertexArray v2: Use fence dep instead of bo_wait (Eric Anholt) v3: Rename struct names (Iago Toral) Document why is not needed on graphics->compute case. (Iago Toral) Follow same code pattern of the other update of in_sync_bcl. v4: Fixed comments style. (Iago Toral) Fixes KHR-GLES31.core.shader_image_load_store.advanced-sync-vertexArray Reviewed-by:
Iago Toral Quiroga <itoral@igalia.com> CC: 19.3 20.0 <mesa-stable@lists.freedesktop.org> Tested-by: Marge Bot <mesa/mesa!2700> Part-of: <mesa/mesa!2700> (cherry picked from commit 01496e3d)
-
Dylan Baker authored
-
- Feb 24, 2020
-
-
spirv_to_nir warns if it encounters XFB decorations and errors if it encounters a Stream decoration with value other than 0, despite the fact that these decorations are in fact handled correctly. Fixes dEQP-VK.transform_feedback.simple.query_1_* Fixes: cd4a14be "spirv: Handle XFB variable decorations" Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Tested-by: Marge Bot <mesa/mesa!3910> Part-of: <mesa/mesa!3910> (cherry picked from commit 5f3cbbd9)
-
Erik Faye-Lund authored
When os_memory_debug.h was promoted to src/util, this source-file on which it depends on when the debug-flag is set on windows was left out. So let's move this also. It doesn't seem there's any way of triggering this issue right now, but it seems better to correct this to avoid this from biting us in the ass in the future. Fixes: 88c4680b ("util: promote u_memory to src/util") Reviewed-by:
Dylan Baker <dylan@pnwbakers> Reviewed-by:
Jose Fonseca <jfonseca@vmware.com> Tested-by: Marge Bot <mesa/mesa!3844> Part-of: <mesa/mesa!3844> (cherry picked from commit 2e3318b1)
-
Dylan Baker authored
-
- Feb 20, 2020
-
-
Danylo Piliaiev authored
We don't support MESA_FORMAT_Z_UNORM16 before Gen8, see intel_screen_init_surface_formats. As a consequence disables B5G6R5_UNORM configs with depth on gen < 6. Closes: mesa/mesa#2275 CC: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Danylo Piliaiev <danylo.piliaiev@globallogic.com> Tested-by: Marge Bot <mesa/mesa!3206> Part-of: <mesa/mesa!3206> (cherry picked from commit 5bfd363b)
-
The other source of the multiply will be interpreted as a uint32_t in an XOR instruction. Any source modifiers with either not be interpreted at all or will be misinterpreted due to the differing types. If the other operand of the multiplication has a source modifier, just emit an extra move to resolve the source modifiers. The negation source modifier problem is difficult to reproduce due to an algebraic optimization that changes (-a*b) to -(a*b). However, changes in MR !1359 push the negations back down. On Gen7+ it might be possible to do slightly better for an abs() source modifier by using BFI2 as a glorified copysign(). On Gen8+ it might be possible to do slightly better for a neg() source modifier by emitting (~a ^ b). There were no shader-db changes on any Intel platform, so I think we can deal with that problem when it arises. See also piglit!224. Fixes: 06d2c116 ("intel/fs: Add a scale factor to emit_fsign") Reviewed-by:
Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <mesa/mesa!3780> Part-of: <mesa/mesa!3780> (cherry picked from commit 273b8cd1)
-