- Oct 30, 2017
-
-
Andres Gomez authored
Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
Signed-off-by: Andres Gomez <agomez@igalia.com>
-
- Oct 27, 2017
-
-
Andres Gomez authored
extra: Commit is not applicable when ade416d0 is missing. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
fixes: This commit addressed earlier commit 35ac13ed which did not land in branch. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
fixes: Commit is not applicable when 6ce55045 is missing. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
fixes: Commit is not applicable when 087e010b is missing. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
stable: 17.3 nominations only. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
stable: Commit is too big for stable at this point. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
Andres Gomez authored
stable: Commits are too invasive for 17.2. Signed-off-by: Andres Gomez <agomez@igalia.com>
-
The PRM says "The execution size must be 1." In 73137997, the execution size was set to 1 when it should have been BRW_EXECUTE_1 (which maps to 0). Later, in dc2d3a7f, JMPI was used for line AA on gen6 and earlier and we started manually stomping the exeution size to BRW_EXECUTE_1 in the generator. This commit fixes the original bug and makes brw_JMPI just do the right thing. Reviewed-by: Matt Turner <mattst88@gmail.com> Fixes: 73137997 (cherry picked from commit 562b8d45)
-
We currently have a bug where nir_lower_system_values gets called before nir_lower_var_copies so it will miss any system value uses which come from a copy_var intrinsic. Moving it to after brw_preprocess_nir fixes this problem. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 279f8fb6) [Andres Gomez: resolve trivial conflicts] Signed-off-by: Andres Gomez <agomez@igalia.com> Conflicts: src/intel/vulkan/anv_pipeline.c
-
In order to implement the ballot intrinsic, we do a MOV from flag register to some GRF. If that GRF is used in a SEL, cmod propagation helpfully changes it into a MOV from the flag register with a cmod. This is perfectly valid but when lower_simd_width comes along, it simply splits into two instructions which both have conditional modifiers. This is a problem since we're reading the flag register. This commit makes us check whether or not flags_written() overlaps with the flag values that we are reading via the instruction source and, if we have any interference, will force us to emit a copy of the source. Reviewed-by: Matt Turner <mattst88@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit fa6e74e3)
-
v2: use a more generic compat function v3: rename and formatting cleanup Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103388 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> Reviewed-by: Francisco Jerez <currojerez@riseup.net> CC: <mesa-stable@lists.freedesktop.org> (cherry picked from commit a6d38f47)
-
Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (cherry picked from commit c1b84256)
-
v2: fix silly typo Cc: "17.2 17.3" <mesa-stable@lists.freedesktop.org> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 27a0b24b) [Andres Gomez: resolve trivial conflicts] Signed-off-by: Andres Gomez <agomez@igalia.com> Conflicts: src/amd/common/ac_nir_to_llvm.c
-
Fixes: 1bcb953e 'radv: handle GFX9 1D textures' Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 2c5b43c8)
-
The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2 registers at context initialization time. Instead, they're inherited from whatever happened to be running on the GPU prior to first run of a new context. So, when we started setting these, other contexts in the system started inheriting our values. Since this controls whether 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong setting is fatal for almost any process which isn't expecting this. Unfortunately, VA-API and Beignet don't initialize this (nor does older Mesa), so they will die horribly if we start doing this. UXA and SNA don't use any push constants, so they are unaffected. Until we have some kind of solution to this problem, I'm going to revert this patch and abandon using the feature for now. It will lead to fewer pushed UBO ranges on Broadwell+, which may lead to lower performance, though I don't have any data on the impact. Cc: "17.3 17.2" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102774 (cherry picked from commit 013d3312) [Andres Gomez: resolve trivial conflicts] Signed-off-by: Andres Gomez <agomez@igalia.com> Conflicts: src/mesa/drivers/dri/i965/brw_state_upload.c src/mesa/drivers/dri/i965/intel_screen.c
-
And just reference pipe_resources to it in the validate callbacks. Avoids pipe_resource leaks when st_framebuffer_validate ends up calling the validate callback multiple times, e.g. when a window is resized. v2: * Use generic stable tag instead of Fixes: tag, since the problem could already happen before the commit referenced in v1 (Thomas Hellstrom) * Use memset to initialize the array on the stack instead of allocating the array with os_calloc. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> (cherry picked from commit 7561da36) Squashed with: st/osmesa: include u_inlines.h for pipe_resource_reference Fixes build failure due to unresolved symbol. Fixes: 7561da36 "st/mesa: Initialize textures array in st_framebuffer_validate" Trivial. (cherry picked from commit 8c9e7c96)
-
Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Henri Verbeet <hverbeet@gmail.com> Fixes: e73d136a ("vulkan/wsi/x11: Implement FIFO mode.") Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (cherry picked from commit 3de87f7c)
-
So one of the CTS tests tries to allocate a 16384x1 2048 array texture. This overflows a bunch of calculations when we want it tiled as the heights goes to 128. addrlib returns us the correct size (16GB or so), but we mangle it in the htile calcs due to the 32-bit offset fields, then userspace gives us the reduced number and we try to allocate it on a heap and things blow up. We really need to give the app back the correct size for the image so we can blow up properly in memory allocation later. This should fix hangs in dEQP-VK.pipeline.render_to_image.core.1d_array.huge.width_layers.r8g8b8a8_unorm_d32_sfloat_s8_uint since Fixes: ad3d98da (radv: enable tc compatible htile for d32s8 also.) Now there's an open question if we should be enabling tc-compat htile at all for shallow textures like the above. This might cause some other wierd side effects in CTS even without the tc compat so: Cc: "17.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 35c66f3e) [Andres Gomez: resolve trivial conflicts] Signed-off-by: Andres Gomez <agomez@igalia.com> Conflicts: src/amd/vulkan/radv_private.h
-
My guess is that the GPU is going to report VM faults if vkCmdDrawIndirectCountAMD() (and friends) are used. 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 3e5f27fa)
-
- Oct 19, 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>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
- Oct 17, 2017
-
-
Emil Velikov authored
The user does not need to know the specifics of the struct, as only a pointer to it is used. Just forward declare the struct making the header self-contained. v2: Remove deprecation warning text/bugzilla - patch does no help there. Cc: Greg V <greg@unrelenting.technology> Fixes: 5cddb1ce ("wayland: Add an extension to create wl_buffers from EGLImages") Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1) (cherry picked from commit 66ebdfbd)
-
Emil Velikov authored
The callbacks may be called even when they are no longer valid. Say, the user is dlclose(ing) libEGL while the buffers are being destroyed. Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Derek Foreman <derekf@osg.samsung.com> (cherry picked from commit 0cfd6f6c)
-
This looks like a copy+paste error. They don't actually write into that variable as would be implied by putting the return there. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 3442c9fc)
-
We didn't fold correctly in the case of 0x1 because we never let the loop counter hit 0. Switching it to bit >= 0 solves this problem. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Connor Abbott <cwabbott0@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit a0947921)
-
Otherwise we could have a failure followed by a smaller write that succeeds and get a corrupted blob. If we ever OOM, we should stop. v2 (Jason Ekstrand): - Initialize the new boolean member in create_blob Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit e03717ef)
-
Otherwise, if you have a large read fail and then try to do a small read, the small read may succeed even though it's at the wrong offset. Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 71188513)
-
These changes were generated using python's `2to3` tool. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102852 Reported-by: Alex Granni <liviuprodea@yahoo.com> Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> (cherry picked from commit 7d48219b)
-
Older kernels fail the va_op with this flag set. If the kernel supports GFX9 usefully, it will also support this flag. Fixes: e8d57802 "radv/gfx9: allocate events from uncached VA space" Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 96f80c8d)
-
The dmabuf interface requires a valid modifier to be sent. If we don't explicitly get a modifier from the driver, we can't know what to send; it must be inferred from legacy side-channels (or assumed to linear, if none exists). If we have no modifier, then we can only have a single-plane format anyway, so fall back to the old wl_drm buffer import path. Fixes: a65db0ad ("st/dri: don't expose modifiers in EGL if the driver doesn't implement them") Fixes: 02cc3593 ("egl/wayland: Use linux-dmabuf interface for buffers") Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reported-by: Andy Furniss <adf.lists@gmail.com> Cc: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit b65d6daf)
-
When creating a wl_buffer from a DRIImage, we extract all the DRIImage information via queryImage. Check whether or not it actually succeeds, either bailing out if the query was critical, or providing sensible fallbacks for information which was not available in older DRIImage versions. Fixes: a65db0ad ("st/dri: don't expose modifiers in EGL if the driver doesn't implement them") Fixes: 02cc3593 ("egl/wayland: Use linux-dmabuf interface for buffers") Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reported-by: Andy Furniss <adf.lists@gmail.com> Cc: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 6273d2f2)
-
Emil Velikov authored
The current convenience function GetEnv feeds the results of getenv directly into std::string(). That is a bad idea, since the variable may be unset, thus we feed NULL into the C++ construct. The latter of which is not allowed and leads to a crash. v2: Better variable name, implicit char* -> std::string conversion (Eric) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101832 Fixes: a25093de ("swr/rast: Implement JIT shader caching to disk") Cc: Tim Rowley <timothy.o.rowley@intel.com> Cc: Laurent Carlier <lordheavym@gmail.com> Cc: Bernhard Rosenkraenzer <bero@lindev.ch> [Emil Velikov: make an actual commit from the misc diff] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1) Reviewed-by: Laurent Carlier <lordheavym@gmail.com> (v1) (cherry picked from commit 21e27102)
-
The hardware does this automatically for unorm formats, but we need to do it manually for unorm depth formats that have been upgraded to Z32_FLOAT. Fixes dEQP-GLES31.functional.texture.border_clamp.range_clamp.nearest_unorm_depth and others. Fixes: d4d9ec55 ("radeonsi: implement TC-compatible HTILE") Reviewed-by: Marek Olšák <marek.olsak@amd.com> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> (cherry picked from commit 6eb94839)
-
The hardware usually does this automatically. However, we upgrade depth to Z32_FLOAT to enable TC-compatible HTILE, which means the hardware no longer clamps the comparison value for us. The only way to tell in the shader whether a clamp is required seems to be to communicate an additional bit in the descriptor table. While VI has some unused bits in the resource descriptor, those bits have unfortunately all been used in gfx9. So we use an unused bit in the sampler state instead. Fixes dEQP-GLES3.functional.texture.shadow.2d.linear.equal_depth_component32f and many other tests in dEQP-GLES3.functional.texture.shadow.* Fixes: d4d9ec55 ("radeonsi: implement TC-compatible HTILE") Reviewed-by: Marek Olšák <marek.olsak@amd.com> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> (cherry picked from commit 4c56e070) [Emil Velikov: handle lack of dirty_mask in original patch] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Conflicts: src/gallium/drivers/radeonsi/si_descriptors.c
-
Found by address sanitizer. The loop here tries to be safe, but in doing so, it ends up doing exactly the wrong thing: the safe foreach is for when the loop variable (inst) could be deleted and nothing else. However, this particular can delete inst's successor, but not inst itself. Fixes: 8c6a0eba ("st/mesa: add st fp64 support (v7.1)") Reviewed-by: Marek Olšák <marek.olsak@amd.com> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> (cherry picked from commit 2703fa61)
-