- Jun 01, 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>
-
- May 31, 2017
-
-
v2: add comment in code Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100741 Fixes: a5e733c6 mesa: drop current draw/read buffer when ctx is released Reviewed-by: Rob Clark <robdclark@gmail.com> (v1) Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit fd6c2a3f) [Emil Velikov: s/CurrentClientDispatch/CurrentDispatch/] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/mesa/main/context.c
-
Emil Velikov authored
Rather than misleadingly depending on DRI2 for the WL_DRM vs WL_SHM formats, use the wl_drm and wl_shm interface respectively. Fixes: a1727aa7 ("egl/wayland: Don't use DRM format codes for SHM") Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 6ef0fc40)
-
Emil Velikov authored
Analogous to previous commit - the compiler can discard xcb + wayland libs, since there is no user (the static libraries) before it on the command line. Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Eduardo Lima Mitev <elima@igalia.com> (cherry picked from commit 2b6ad89d)
-
Emil Velikov authored
The compiler can discard the shared ones from the link chain, since there is no user (the static libraries) before it on the command line. Cc: mesa-stable@lists.freedesktop.org Reported-by:
Laurent Carlier <lordheavym@gmail.com> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Eduardo Lima Mitev <elima@igalia.com> (cherry picked from commit 3e8790bf)
-
The width and height of the copy don't have to be aligned to the block size if they specify the right or bottom edges of the image. (See also the comment and asserts right above). We need to round them up when we do the division in order to get it 100% right. Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: "17.0 17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0901d0bc)
-
We've discovered in the Vulkan driver that simply doing the end-of-pipe sync afterwards is insufficient. The specific requirement stated in the PRM is that you have to do one every time you transition between the tree modes of "clear", "render", and "resolve". This is GL, so we could track it but any attempt to do so would most likely get it wrong. For now, it's easier to just assume that every fast-clear op is an island and do the sync both before and after. This also removes the unneeded flush and stall after slow-clear operations. Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> Cc: "17.0 17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 441cd7a8)
-
- May 26, 2017
-
-
Commit 9ca6711f changed the Wayland winsys to only block for the frame callback inside SwapBuffers, rather than get_back_bo. get_back_bo would perform a single non-blocking Wayland event dispatch, to try to find any release events which we had pulled off the wire but not actually processed. The blocking dispatch was moved to SwapBuffers. This removed a guarantee that we would've processed all events inside get_back_bo(), and introduced a failure whereby the server could've sent a buffer release event, but we wouldn't have read it. In clients unconstrained by SwapInterval (rendering ~as fast as possible), which were being displayed directly without composition (buffer release delayed), this could lead to get_back_bo() failing because there were no free buffers available to it. The drawing rightly failed, but this was papered over because of the path in eglSwapBuffers() which attempts to guarantee a BO, in order to support calling SwapBuffers twice in a row with no rendering actually having been performed. Since eglSwapBuffers will perform a blocking dispatch of Wayland events, a buffer release would have arrived by that point, and we could then choose a buffer to post to the server. The effect was that frames were displayed out-of-order, since we grabbed a frame with random past content to display to the compositor. Ideally get_back_bo() failing should store a failure flag inside the surface and cause the next SwapBuffers to fail, but for the meantime, restore the correct behaviour such that get_back_bo() no longer fails. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reported-by:
Eero Tamminen <eero.t.tamminen@intel.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98833 Fixes: 9ca6711f ("Revert "wayland: Block for the frame callback in get_back_bo not dri2_swap_buffers"") (cherry picked from commit 1f2d0093)
-
During display initialisation, we need a separate event queue to handle the registry events, which is correctly handled. But we also need separate per-surface event queues to handle swapchain-related events, such as surface frame events and buffer release events. This avoids two surfaces from the same EGLDisplay, both current on separate threads, dispatching each other's events. Create separate per-surface event queues, create wl_surface and wl_drm proxy wrapper objects per surface, so we eliminate the race around sending events to the wrong queue. swrast buffers do not need a dedicated proxy wrapper, as the wl_shm_pool used to create the wl_buffers, being transient, can itself be assigned to a queue. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 36b9976e ("egl/wayland: Avoid race conditions when on non-main thread") Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 03dd9a88) Squashed with: egl/wayland: verify event queue was allocated We're already verified that 'window' wasn't NULL, I'm guessing this allocation error is about the newly created queue. CID: 1409754 Fixes: 03dd9a88 ("egl/wayland: Use per-surface event queues") Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> (cherry picked from commit 30dc56bb)
-
wl_display_roundtrip_queue() exists and can replace roundtrip(). The API was introduced with wayland 1.6, while we currently require 1.11. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 8118bc26)
-
Though most swapchain operations used a queue, they were racy in that the object was created with the queue only set later, meaning that its event could potentially be dispatched from the default queue in between these two steps. Use proxy wrappers to avoid this race, also assigning wl_buffers created for the swapchain to the event queue. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 5034c615) [Emil Velikov: wsi_wl_swapchain is missing surface_version, move image_count] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/vulkan/wsi/wsi_common_wayland.c Squahed with: vulkan/wsi/wayland: Fix proxy wrappers for swapchain recreation Before the swapchain event queue is destroyed, all proxy objects that reference it must be dropped. Otherwise we risk a use-after-free if a frame callback event or buffer release events are received afterwards. This happens when an application destroys and recreates a swapchain in FIFO mode between two frames without using the VkSwapchainCreateInfoKHR::oldSwapchain mechanism to keep the old swapchain until after the next redraw. Fixes: 5034c615 ("vulkan/wsi/wayland: Use proxy wrappers for swapchain") Signed-off-by:
Philipp Zabel <philipp.zabel@gmail.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 1586768e) [Emil Velikov: image_count is not in base] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/vulkan/wsi/wsi_common_wayland.c
-
Calling random callbacks on the display's event queue is hostile, as we may call into client code when it least expects it. Create our own event queue, one per wsi_wl_display, and use that for the registry. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit c902a195)
-
There's no need to call wl_display_roundtrip() after trying to create a buffer through wl_drm; if it succeeds then everything is fine, and if it fails, then we get a fatal protocol error so can't recover anyway. Additionally, doing a roundtrip on the default / main application queue, is destructive anyway, so would need to be its own queue. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit afe8c8a2)
-
Untangle the exit cleanup paths so we don't try to use the registry variable before it's been initialised. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit d9a8bba7)
-
The instruction encodings only allow for immediates. Don't try to replace a zero (which is dumb to have in that op in any case) with RZ. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 82e77d4e)
-
Emil Velikov authored
It's been like this since the code was introduced. Fixes: 86eb4131 (st/va: add headless support, i.e. VA_DISPLAY_DRM) Cc: <mesa-stable@lists.freedesktop.org> Cc: Julien Isorce <julien.isorce@gmail.com> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Nayan Deshmukh <nayan26deshmukh@gmail.com> Reviewed-by:
Christian König <christian.koenig@amd.com> (cherry picked from commit aaea53c2)
-
The procedure for decompressing an opaque DXT1 OpenGL format is dependant on the comparison of two colors stored in the first 32 bits of the compressed block. Here's the specified OpenGL behavior for reference: The RGB color for a texel at location (x,y) in the block is given by: RGB0, if color0 > color1 and code(x,y) == 0 RGB1, if color0 > color1 and code(x,y) == 1 (2*RGB0+RGB1)/3, if color0 > color1 and code(x,y) == 2 (RGB0+2*RGB1)/3, if color0 > color1 and code(x,y) == 3 RGB0, if color0 <= color1 and code(x,y) == 0 RGB1, if color0 <= color1 and code(x,y) == 1 (RGB0+RGB1)/2, if color0 <= color1 and code(x,y) == 2 BLACK, if color0 <= color1 and code(x,y) == 3 The sampling operation performed on an opaque DXT1 Intel format essentially hard-codes the comparison result of the two colors as color0 > color1. This means that the behavior is incompatible with OpenGL. This is stated in the SKL PRM, Vol 5: Memory Views: Opaque Textures (DXT1_RGB) Texture format DXT1_RGB is identical to DXT1, with the exception that the One-bit Alpha encoding is removed. Color 0 and Color 1 are not compared, and the resulting texel color is derived strictly from the Opaque Color Encoding. The alpha channel defaults to 1.0. Programming Note Context: Opaque Textures (DXT1_RGB) The behavior of this format is not compliant with the OGL spec. The opaque and non-opaque DXT1 OpenGL formats are specified to be decoded in exactly the same way except the BLACK value must have a transparent alpha channel in the latter. Use the four-channel BC1 Intel formats with the alpha set to 1 to provide the behavior required by the spec. Note that the alpha is already set to 1 for RGB formats in brw_get_texture_swizzle(). v2: Provide a more detailed commit message (Kenneth Graunke). v3: Ensure the alpha channel is set to 1 for DXT1 formats. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100925 Cc: <mesa-stable@lists.freedesktop.org> Acked-by: Tapani Pälli <tapani.palli@intel.com> (v1) Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> (cherry picked from commit 688ddb85) [Emil Velikov: attribute for BRW to ISL format rename] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/mesa/drivers/dri/i965/brw_surface_formats.c
-
The procedure for decompressing an opaque BC1 Vulkan format is dependant on the comparison of two colors stored in the first 32 bits of the compressed block. Here's the specified OpenGL (and Vulkan) behavior for reference: The RGB color for a texel at location (x,y) in the block is given by: RGB0, if color0 > color1 and code(x,y) == 0 RGB1, if color0 > color1 and code(x,y) == 1 (2*RGB0+RGB1)/3, if color0 > color1 and code(x,y) == 2 (RGB0+2*RGB1)/3, if color0 > color1 and code(x,y) == 3 RGB0, if color0 <= color1 and code(x,y) == 0 RGB1, if color0 <= color1 and code(x,y) == 1 (RGB0+RGB1)/2, if color0 <= color1 and code(x,y) == 2 BLACK, if color0 <= color1 and code(x,y) == 3 The sampling operation performed on an opaque DXT1 Intel format essentially hard-codes the comparison result of the two colors as color0 > color1. This means that the behavior is incompatible with OpenGL and Vulkan. This is stated in the SKL PRM, Vol 5: Memory Views: Opaque Textures (DXT1_RGB) Texture format DXT1_RGB is identical to DXT1, with the exception that the One-bit Alpha encoding is removed. Color 0 and Color 1 are not compared, and the resulting texel color is derived strictly from the Opaque Color Encoding. The alpha channel defaults to 1.0. Programming Note Context: Opaque Textures (DXT1_RGB) The behavior of this format is not compliant with the OGL spec. The opaque and non-opaque BC1 Vulkan formats are specified to be decoded in exactly the same way except the BLACK value must have a transparent alpha channel in the latter. Use the four-channel BC1 Intel formats with the alpha set to 1 to provide the behavior required by the spec. v2 (Kenneth Graunke): - Provide a more detailed commit message. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100925 Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> (cherry picked from commit 56458cb1)
-
The datalayout for modules was purposely not being set in order to work around the fact that the ExecutionEngine requires that the module's datalayout matches the datalayout of the TargetMachine that the ExecutionEngine is using. When the pass manager runs on a module with no datalayout, it uses the default datalayout which is little-endian. This causes problems on big-endian targets, because some optimizations that are legal on little-endian or illegal on big-endian. To resolve this, we set the datalayout prior to running the pass manager, and then clear it before creating the ExectionEngine. This patch fixes a lot of piglit tests on big-endian ppc64. Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 14e525a4)
-
Fixes regressions in Android CtsVerifier.apk on Intel Chrome OS devices due to incorrect error handling in eglMakeCurrent. See below on how to confirm the regression is fixed. This partially reverts commit 23c86c74 Author: Chad Versace <chadversary@chromium.org> Subject: egl: Emit error when EGLSurface is lost The problem with commit 23c86c74 is that, once an EGLSurface became lost, the app could never unbind the bad surface. Each attempt to unbind the bad surface with eglMakeCurrent failed with EGL_BAD_CURRENT_SURFACE. Specificaly, the bad commit added the error handling below. #2 and #3 were right, but #1 was wrong. 1. eglMakeCurrent emits EGL_BAD_CURRENT_SURFACE if the calling thread has unflushed commands and either previous surface is no longer valid. 2. eglMakeCurrent emits EGL_BAD_NATIVE_WINDOW if either new surface is no longer valid. 3. eglSwapBuffers emits EGL_BAD_NATIVE_WINDOW if the swapped surface is no longer valid. Whe I wrote the bad commit, I misunderstood the EGL spec language for #1. The correct behavior is, if I understand correctly now, is below. This patch doesn't implement the correct behavior, though, it just reverts the broken behavior. - Assume a bound EGLSurface is no longer valid. - Assume the bound EGLContext has unflushed commands. - The app calls eglMakeCurrent. The spec requires eglMakeCurrent to implicitly flush. After flushing, eglMakeCurrent emits EGL_BAD_CURRENT_SURFACE and does *not* alter the thread's current bindings. - If the app calls eglMakeCurrent again, and the app inserts no commands into the GL command stream between the two eglMakeCurrent calls, then this second eglMakeCurrent succeeds without emitting an error. How to confirm this fixes the regression: Download android-cts-verifier-7.1_r5-linux_x86-x86.zip from source.android.com, unpack, and `adb install CtsVerifier.apk`. Run test "Projection Cube". Click the Pass button (a green checkmark). Then run test "Projection Widget". Confirm that widgets are visible and that logcat does not complain about eglMakeCurrent failure. Then confirm there are no regressions in the cts-traded module that commit 263243b1 fixed: cts-tf > run cts --skip-preconditions --skip-device-info \ -m CtsCameraTestCases \ -t android.hardware.camera2.cts.RobustnessTest Tested with Chrome OS board "reef". Fixes: 23c86c74 (egl: Emit error when EGLSurface is lost) Acked-by:
Tapani Pälli <tapani.palli@intel.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Nicolas Boichat <drinkcat@chromium.org> Cc: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 8f62d21b)
-
Reorder the uniforms to load first the dvec4-aligned variables in the push constant buffer and then push the vec4-aligned ones. It takes into account that the relocated uniforms should be aligned to their channel size. This fixes a bug were the dvec3/4 might be loaded one part on a GRF and the rest in next GRF, so the region parameters to read that could break the HW rules. v2: - Fix broken logic. - Add a comment to explain what should be needed to optimise the usage of the push constant buffer slots, as this patch does not pack the uniforms. v3: - Implemented the push constant buffer usage optimization. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> Acked-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit e69e5c70)
-
It was setting XYWZ swizzle and writemask to all uniforms, no matter if they were a vector or scalar, so this can lead to problems when loading them to the push constant buffer. Moreover, 'shift' calculation was designed to calculate the offset in DWORDS, but it doesn't take into account DFs, so the calculated swizzle for the later ones was wrong. The indirect case is not changed because MOV INDIRECT will write to all components. Added an assert to verify that these uniforms are aligned. v2: - Fix 'shift' calculation (Curro) - Set both swizzle and writemask. - Add assert(shift == 0) for the indirect case. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit 8aa6ada8)
-
We are going to add a packing feature to reduce the usage of the push constant buffer. One of the consequences is that 'nr_params' would be modified by vec4_visitor's run call, so we need to restore it if one of them failed before executing the fallback ones. Same thing happens to the uniforms values that would be reordered afterwards. Fixes GL45-CTS.arrays_of_arrays_gl.InteractionFunctionCalls2 when the dvec4 alignment and packing patch is applied. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> Acked-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit 354f7f2c)
-
If X11 did a software fallback to the entire screen, we would throw out the BO the screen is scanning out from and allocate a new one. Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit e8ea42d2)
-
Together with some fixes to xdriinfo this fixes xdriinfo not working with glvnd. Since apps (xdriinfo) expect GetDriverConfig to work without going to need through the dance to setup a glxcontext (which is a reasonable expectation IMHO), the dispatch for this ends up significantly different then any other dispatch function. This patch gets the job done, but I'm not really happy with how this patch turned out, suggestions for a better fix are welcome. Cc: Kyle Brenneman <kbrenneman@nvidia.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 84f764a7)
-
The reasoning Chad gave in the comment for choosing a valign of 4 is entirely bunk. The fact that you have to multiply pitch by 2 is completely unrelated to the halign/valign parameters used for texture layout. (Not completely unrelated. W-tiling is just Y-tiling with a bit of extra swizzling which turns 8x8 W-tiled chunks into 16x4 y-tiled chunks so it makes everything easier if miplevels are always aligned to 8x8.) The fact that RENDER_SURFACE_STATE::SurfaceVerticalAlignmet doesn't have a VALIGN_8 option doesn't matter since this is gen7 and you can't do stencil texturing anyway. v2 (Jason Ekstrand): - Delete most of Chad's comment and add a more descriptive commit message. Signed-off-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> Cc: "17.0 17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Chad Versace <chadversary@chromium.org> (cherry picked from commit 236f17a9)
-
PIPE_BUFFER is a target enum, not a binding. This caused the driver to up-align the height of buffer resources, leading to largely oversizing those resources. This is especially bad, as the buffer resources used by the upload manager are already 1MB in size. Height alignment meant that those would result in 4 to 8MB big BOs. Fixes: c9e8b49b ("etnaviv: gallium driver for Vivante GPUs") Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-By:
Wladimir J. van der Laan <laanwj@gmail.com> Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> (cherry picked from commit 8173d7d9)
-
vc4 was rejecting renderonly's import, because the offset field was nonzero. Fixes: 848b49b2 ("gallium: add renderonly library") Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> (cherry picked from commit c98f03c6)
-
- May 12, 2017
-
-
Andres Gomez authored
Signed-off-by:
Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
Signed-off-by:
Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
Signed-off-by:
Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
stable: rejected commits. Signed-off-by:
Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
fixes: Fixes earlier commit 126d5adb which did not land in branch Signed-off-by:
Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
stable: 17.1 nominations only. Signed-off-by:
Andres Gomez <agomez@igalia.com>
-
Cc: 17.1 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit ee590839) [Andres Gomez: resolve trivial conflicts] Signed-off-by:
Andres Gomez <agomez@igalia.com> Conflicts: src/gallium/drivers/radeonsi/si_state_draw.c
-
This just adds the chip in the right places. We don't set the partial_vs_wave workaround, as radeonsi doesn't, but have to confirm it's not required. Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: "17.1" <mesa-stable@lists.freedesktop.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit a096d8d3) [Andres Gomez: dropped code that didn't make it for 17.0] Signed-off-by:
Andres Gomez <agomez@igalia.com> Conflicts: src/amd/vulkan/radv_device.c
-
Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit f16b7558)
-
Possibly other gen's have a similar limit. Fixes glmark2 -b shadow with larger resolutions on devices with small gmem (for example, fullscreen 1080p on 8x16/db410c). Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Rob Clark <robdclark@gmail.com> (cherry picked from commit 6050d5bf)
-
LLVMDemangle, LLVMGlobalISel, and LLVMDebugInfoMSF are new. Also update the comment to add irreader to the list of components. CC: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Chuck Atkins <chuck.atkins@kitware.com> Signed-off-by:
Ben Boeckel <ben.boeckel@kitware.com> Acked-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Jose Fonseca <jfonseca@vmware.com> (cherry picked from commit 58f51f07)
-