- Aug 22, 2018
-
-
Andres Gomez authored
Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
fixes: This commit has more than one Fixes tag but the commit it addresses didn't land in branch. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
- Aug 21, 2018
-
-
With the current code, we didn't do the space checks prior to atomic counter setup emission, but we also didn't add atomic counters to the space check so we could get a flush later as well. These flushes would be bad, and lead to problems with parallel tests. We have to ensure the atomic counter copy in, draw emits and counter copy out are kept in the same command submission unit. This reworks the code to drop some useless masks, make the counting separate to the emits, and make the space checker handle atomic counter space. [airlied: want this in 18.2] Fixes: 06993e4e (r600: add support for hw atomic counters. (v3)) (cherry picked from commit 32529e60)
-
We use floating-points for viewport bounds so VIEWPORT_SUBPIXEL_BITS should reflect this. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105975 Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (cherry picked from commit 25ec806e)
-
- Aug 20, 2018
-
-
This fixes a regression with some Unity demos. Not sure what the root cause of the problem is, especially because the driver doesn't perform any fast color clears. So, it shouldn't be needed to decompress DCC. RadeonSI says that the decompression is relatively cheap if the surface has been decompressed already. One possible improvement is to two use predicates, one for DCC and one for FCE that could be cleared when DCC, FMASK or CMASK are performed by the driver. That might skip some unnecessary decompression passes (not DCC though). Fixes: ff7daadc ("radv: enable/disable predication for the DCC decompression pass") CC: 18.2 <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107563 Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 0aacb5ea)
-
- Aug 17, 2018
-
-
At the moment, depending on pipe transfer flags, the dumb buffer map address can end up at either kms_sw_dt->ro_mapped or kms_sw_dt->mapped. When it's time to unmap the dumb buffer, both locations get unmapped, even though one is probably initialized to 0. That leads to the code segment getting unmapped at runtime and crashes when trying to call into unrelated code. This commit addresses the problem by using MAP_FAILED instead of NULL for ro_mapped and mapped when the dumb buffer is unmapped, and only unmapping mapped addresses at unmap time. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107098 Signed-off-by: Ray Strode <rstrode@redhat.com> Fixes: d891f28d ("gallium/winsys/kms: Fix possible leak in map/unmap.") Cc: Lepton Wu <lepton@chromium.org> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 9baff597)
-
Because lower_ycbcr gets called before apply_pipeline_layout, the indices are all logical and the binding layout HW size is actually too big for the bounds check. We should just use the regular logical array size instead. Fixes: f3e91e78 "anv: add nir lowering pass for ycbcr textures" Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (cherry picked from commit 320dacb0)
-
When the number of unique BO is 0, we optimize the list creation by copying all buffers of the current CS directly into it. But this is only valid if the CS doesn't have virtual buffers, otherwise they are not added and hw might report VM faults. This fixes VM faults with: dEQP-VK.sparse_resources.image_sparse_binding.2d.rgba8ui.1024_128_1 CC: <mesa-stable@lists.freedesktop.org> Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit d27e1584)
-
- Aug 16, 2018
-
-
Compiling EGL's platform_x11 without dri3 and gbm yields this compile failure: platform_x11 needs inc_loader: ../mesa-18.2.0-rc2/src/egl/drivers/dri2/platform_x11.c:48:10: fatal error: loader.h: No such file or directory #include "loader.h" ^~~~~~~~~~ Fixes: 108d257a ("meson: build libEGL") Bugzilla: https://bugs.gentoo.org/663534 Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 9a96bf0e)
-
We have to do a fast-clear eliminate when clearing DCC metadata with 0x20202020. I don't know if that fixes anything but that seems correct to me. CC: 18.2 <mesa-stable@lists.freedesktop.org> Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit f9e8456c)
-
This was missing when VK_EXT_conditional_rendering has been implemented. The predication type should be -1 to avoid restoring previous state when performing a decompression pass with DCC enabled. Note that we don't have to handle secondary command buffers because we don't support this feature currently. CC: 18.2 <mesa-stable@lists.freedesktop.org> Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit f3a78a9d)
-
Seems like DXVK depends on that and it might get reverted upstream. Since apps are not supposed to use 0 in v2 anyway, we should be safe implementing the old behavior there. Fixes: 66e12451 "radv: Update to new VK_EXT_vertex_attribute_divisor to version 2." CC: 18.2 <mesa-stable@lists.freedesktop.org> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 011a8116)
-
Accessing scalar constant as an array in function call or initializer list triggered assert in get_array_element. Examples: func(0[0]); vec2 t = { 0[0], 0 }; Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107550 Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com> Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (cherry picked from commit 479a849a)
-
- Aug 15, 2018
-
-
Commit 4434591b caused substantially more URB messages in geometry and tessellation shaders. Before we can really enable this sort of optimization, We either need some way of combining them back together into vectors or we need to do cross-stage vector element elimination without splitting everything into scalars. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107510 Fixes: 4434591b "intel/nir: Call nir_lower_io_to_scalar_early" Acked-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Mark Janes <mark.a.janes@intel.com> (cherry picked from commit 10f44da7)
-
Kernel (for ppgtt) requires memory address to be aligned to page size (4096). -v2: added marking that also fixes initial commit 01058a55. -v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned instead of alignment of offsets (Chris Wilson). -v4: changes related to PAGE_SIZE moved to separate commit -v5: restored alignment to page-size for 0-size. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106997 Fixes: a363bb2c (i965: Allocate VMA in userspace for full-PPGTT systems.) Fixes: 01058a55 (i965: Add virtual memory allocator infrastructure to brw_bufmgr.) Signed-off-by: Sergii Romantsov <sergii.romantsov@globallogic.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (cherry picked from commit 24839663)
-
Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit f0a8accb)
-
This option allows us to remove additional s_waitcnt instructions because s_barrier internally does s_waitcnt 0. Though, apparently there is a problem with LDS accesses that causes rendering issues with FFXV and DXVK. Disable this optimization for now (RadeonSI still uses it). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107460 CC: 18.2 <mesa-stable@lists.freedesktop.org> Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 71d5b2fb)
-
This patch fixes a regression in mesa 18.2 and mesa-dev branches for HAVE_DRM_GRALLOC code path which is causing black screen on Android and prevents boot due to SIGSEGV MAPERR crash related to unproper handling of drm_gralloc drm FD in new droid_open_device() path. Problem is due to c7bb8213 ("egl/android: Add DRM node probing and filtering") To avoid the crash the former existing working droid_open_device() is restored, renamed droid_open_device_drm_gralloc() and kept within HAVE_DRM_GRALLOC braces. Tested with mesa-dev and mesa 18.2 branch and oreo-x86 bootanimation and Androdi GUI booting is fixed with i965, nouveau, radeon. The changes are compatible with gbm_gralloc, I've tested build with hwc too. (v2) remove indentation from HAVE_DRM_GRALLOC pre-processor directive NOTE: Definition of enum{} for GRALLOC_MODULE_PERFORM_GET_DRM_FD is not necessary and it's actually causing a redefinition building error, because in HAVE_DRM_GRALLOC path gralloc_drm.h is already exported by libgralloc_drm which is currently still a dependency. Fixes: c7bb8213 ("egl/android: Add DRM node probing and filtering") Cc: "18.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> (cherry picked from commit 73b342c7)
-
Andres Gomez authored
Signed-off-by: Andres Gomez <agomez@igalia.com>
-
- Aug 14, 2018
-
-
Follow radeonsi. Fixes: 3665f66e "radv: Add support for ETC2 textures." Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 4bb6c493)
-
Behavior wrt firstInstance got changed, and a divisor of 0 has been disallowed. The new version of the ext got published in specification 1.1.81. Sending to stable since the only known user is DXVK, which needs this for correctness. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> CC: 18.2 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 66e12451)
-
CC: <mesa-stable@lists.freedesktop.org> Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit bf33ca75)
-
- Aug 13, 2018
-
-
One of the reasons we didn't notice that R24_UNORM_X8_TYPELESS destinations were broken was that an earlier layer was swapping it out for B8G8R8A8_UNORM. That made Z24X8 -> Z24X8 blits work. However, R32_FLOAT -> R24_UNORM_X8_TYPELESS was still totally broken. The old code only considered one format at a time, without thinking that format conversion may need to occur. This patch moves the translation out to a place where it can consider both formats. If both are Z24X8, we continue using B8G8R8A8_UNORM to avoid having to do shader math workarounds. If we have a Z24X8 destination, but a non-matching source, we use our shader hacks to actually render to it properly. Fixes: 804856fa (intel/blorp: Handle more exotic destination formats) Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit de57926d)
-
The hardware doesn't support rendering to R24_UNORM_X8_TYPELESS, so Jason decided to fake it with a bit of shader math and R32_UNORM RTs. The only problem is that R32_UNORM isn't renderable either...so we've just traded one bad format for another. This patch makes us use R32_UINT instead. Fixes: 804856fa (intel/blorp: Handle more exotic destination formats) Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 8a290862)
-
The Vulkan 1.1.82 spec flipped the order to better match D3D. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> (cherry picked from commit a9f7bcfd)
-
- Aug 10, 2018
-
-
The check for ETC2 compatibility was not updated when the fallback format was changed. Fixes: 71867a0a st/mesa: Fall back to R8G8B8A8_SRGB for ETC2 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit e94095ec)
-
This is basically copied from the DRI2 destroy path. Without this, Raspberry Pi would quickly run out of CMA during the EGL tests in the CTS due to all the pixmaps laying around. Fixes: f35198ba ("egl/x11: Implement dri3 support with loader's dri3 helper") Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (cherry picked from commit b618d7ea)
-
When the SIMD16 Gen4-5 fragment shader payload contains source depth (g2-3), destination stencil (g4), and destination depth (g5-6), the single register of stencil makes the destination depth unaligned. We were generating this instruction in the RT write payload setup: mov(16) m14<1>F g5<8,8,1>F { align1 compr }; which is illegal, instructions with a source region spanning more than one register need to be aligned to even registers. This is because the hardware implicitly does (nr | 1) instead of (nr + 1) when splitting the compressed instruction into two mov(8)'s. I believe this would cause the hardware to load g5 twice, replicating subspan 0-1's destination depth to subspan 2-3. This showed up as 2x2 artifact blocks in both TIS-100 and Reicast. Normally, we rely on the register allocator to even-align our virtual GRFs. But we don't control the payload, so we need to lower SIMD widths to make it work. To fix this, we teach lower_simd_width about the restriction, and then call it again after lower_load_payload (which is what generates the offending MOV). Fixes: 8aee87fe (i965: Use SIMD16 instead of SIMD8 on Gen4 when possible.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107212 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=13728 Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Diego Viola <diego.viola@gmail.com> (cherry picked from commit 08a5c395)
-
This extension is not defined for indirect contexts. Marking it as "client only", as the old code did here, would make the extension available in indirect contexts, even though the server would certainly not have it in its extension list. Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 63a6b719)
-
Return ir_rvalue::error_value with ast_post_inc, ast_post_dec if parser error was emitted previously. This way process_array_size won't see bogus IR generated like with commit 9c676a64. Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98699 Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> (cherry picked from commit 03a5acec)
-
This fixes both Metro 2033 Redux and Metro Last Light Redux Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99730 Signed-off-by: Eero Tamminen <eero.t.tamminen@intel.com> Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com> Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (cherry picked from commit e0de26ea)
-
- Aug 09, 2018
-
-
Fixes: 6a60beba "intel/tools: Add an error state to aub translator" Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (cherry picked from commit aac80f75)
-
We won't have an FD if we're just having the server wait on a fence created by eglCreateSyncKHR(). Our seqno fences will happen in order, so server-side waits are no-ops in that case. Fixes dEQP-EGL.functional.sharing.gles2.multithread.simple_egl_server_sync.buffers.gen_delete Fixes: b0acc3a5 ("broadcom/vc4: Native fence fd support") (cherry picked from commit cfe69d0a)
-
With earlier rework the user and provider of the symbol are within the same binary. Thus there's no point in exporting the function. Spotted while reviewing patch from Chuck, that nearly added another unneeded PUBLIC function. Cc: Chuck Atkins <chuck.atkins@kitware.com> Cc: Tim Rowley <timothy.o.rowley@intel.com> Fixes: f50aa214 "(swr: build driver proper separate from rasterizer") Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Tested-by: Chuck Atkins <chuck.atkins@kitware.com> Reviewed-By: George Kyriazis <george.kyriazis@intel.com<mailto:george.kyriazis@intel.com>> Tested-by: Chuck Atkins <chuck.atkins@kitware.com<mailto:chuck.atkins@kitware.com>> (cherry picked from commit 54d84489)
-
According to EGL 1.5 spec, section 3.10.1.1 ("Native Window Resizing"): "If the native window corresponding to _surface_ has been resized prior to the swap, _surface_ must be resized to match. _surface_ will normally be resized by the EGL implementation at the time the native window is resized. If the implementation cannot do this transparently to the client, then *eglSwapBuffers* must detect the change and resize surface prior to copying its pixels to the native window." So far, resizing a native window in Wayland/EGL was interpreted in Mesa as a request to resize, which is not executed until the first draw call. And hence, surface size is not updated until executing it. Thus, querying the surface size with eglQuerySurface() after a window resize still returns the old values. This commit updates the surface size values as soon as the resize is done, even when the real resize is done in the draw call. This makes the semantics that any native window resize request take effect inmediately, and if user calls eglQuerySurface() it will return the new resized values. v2: update surface size if there isn't a back surface (Daniel) CC: Daniel Stone <daniel@fooishbar.org> CC: mesa-stable@lists.freedesktop.org Reviewed-by: Daniel Stone <daniels@collabora.com> (cherry picked from commit a9fb331e)
-
When creating a windows surface with eglCreateWindowSurface(), the width and height returned by eglQuerySurface(EGL_{WIDTH,HEIGHT}) is invalid until buffers are updated (like calling glClear()). But according to EGL 1.5 spec, section 3.5.6 ("Surface Attributes"): "Querying EGL_WIDTH and EGL_HEIGHT returns respectively the width and height, in pixels, of the surface. For a window or pixmap surface, these values are initially equal to the width and height of the native window or pixmap with respect to which the surface was created" This fixes dEQP-EGL.functional.color_clears.* CTS tests v2: - Do not modify attached_{width,height} (Daniel) - Do not update size on resizing window (Brendan) CC: Daniel Stone <daniel@fooishbar.org> CC: Brendan King <brendan.king@imgtec.com> CC: mesa-stable@lists.freedesktop.org Tested-by: Eric Engestrom <eric@engestrom.ch> Tested-by: Chad Versace <chadversary@chromium.org> Reviewed-by: Chad Versace <chadversary@chromium.org> Reviewed-by: Daniel Stone <daniels@collabora.com> (cherry picked from commit 1fe7cbdf)
-
This is more of a hack, since glvnd itself should be providing the file. Until that happens, ensure the libs is correctly set to -lGL CC: <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 315c46cf)
-
It's not a thing that can work, nor is a wise idea to attempt. v2: Tweak error message (Dylan) CC: <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (v1) (cherry picked from commit 25a9450a)
-
The toggles were broken with the introduction of --enable-mangling. Fixing that up might be possible, but it's not worth the complexity since one can rename the libraries at any point. CC: <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit d5ac2364)
-
This has been a requirement for ages, yet it seems like we never explicitly errored out during configure. CC: <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit a7ea7511)
-