- Feb 13, 2020
-
-
Dylan Baker authored
-
Dylan Baker authored
-
- Feb 11, 2020
-
-
In presence of NaNs, "!(flt(a, b) && flt(c, d))" is NOT EQUAL to "fge(a, b) || fge(c, d)". These optimizations are unsafe for apps that rely on NaN behaviour. pipeline-db (GFX9/LLVM): Totals from affected shaders: SGPRS: 3176 -> 3136 (-1.26 %) VGPRS: 2188 -> 2144 (-2.01 %) Spilled SGPRs: 227 -> 169 (-25.55 %) Code Size: 150572 -> 151800 (0.82 %) bytes Max Waves: 307 -> 310 (0.98 %) pipeline-db (GFX9/ACO): Totals from affected shaders: SGPRS: 18744 -> 18744 (0.00 %) VGPRS: 15576 -> 15580 (0.03 %) Spilled SGPRs: 164 -> 164 (0.00 %) Code Size: 1573012 -> 1576492 (0.22 %) bytes Max Waves: 1534 -> 1532 (-0.13 %) Closes: mesa/mesa#2127 Fixes: d1ed4ffe ("nir: Use De Morgan's Law on logic compounded comparisons") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Tested-by: Marge Bot <mesa/mesa!3696> Part-of: <mesa/mesa!3696> (cherry picked from commit 8e772807)
-
Emma Anholt authored
This reverts the functional part of commit d17ff2f7, leaving the unit test for mesa/pipe agreement on what's an array. The issue is that the util_channel_desc.shift values on array formats are not used for bit addressing in memory, they're bit addressing within a word treating a pixel of the format as a native type, as seen by llvmpipe's use of the values to do shifts (see lp_build_unpack_arith_rgba_aos() for example). This means the values are nonsensical for 3-byte RGB, but then llvmpipe doesn't expose those formats so it works out. I still want to clean up our big-endian format handling at some point, but let's fix the s390x regression first, sort out our format unit tests in CI, then be able to refactor with confidence. Fixes: d17ff2f7 ("gallium: Fix big-endian addressing of non-bitmask array formats.") Closes: #2472 Acked-by: Marek Olšák <marek.olsak@amd.com> Tested-by: Marge Bot <mesa/mesa!3721> Part-of: <mesa/mesa!3721> (cherry picked from commit 1886dbfe)
-
Marek Olšák authored
Cc: 19.3 20.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!3646> (cherry picked from commit fbb27eeb)
-
Since we are now using sparse matrix for format_conversion_table, we have to make sure we have last entry in table which gives the sense of required size of format_conversion_table Fixes: 84db6ba7 ("svga: Drop unsupported formats from the format table") Reviewed-by: Charmaine Lee <charmainel@vmware.com> (cherry picked from commit 470e73e7)
-
Dylan Baker authored
-
- Feb 10, 2020
-
-
pImageIndices should be a pointer to the current image index otherwise every swapchain but the first one could have a wrong image index Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Marge Bot <mesa/mesa!3741> Part-of: <mesa/mesa!3741> (cherry picked from commit 7283c33b)
-
The previous commit leads to match immed values unexpectedly. This makes constlen for each shader including bvert wrong. Also fixes atan2 for mediump deqp tests. Fixes: cbd1f474 ("freedreno/ir3: convert back to 32-bit values for half constant registers.") v2: Move conversion up above fabs/fneg modifier handling as well. Part-of: <mesa/mesa!3737> (cherry picked from commit 260bd32b)
-
Dylan Baker authored
-
- Feb 07, 2020
-
-
The render pass already does the transition. The pipeline barrier is still needed to transfer the queue family ownership. Fixes: 320b0f66 ("vulkan/overlay: bounce image back to present layout") Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Marge Bot <mesa/mesa!3740> Part-of: <mesa/mesa!3740> (cherry picked from commit f239bb80)
-
This fixes two issues: - a crash if the application uses more than one semaphore for presenting because the driver expects one stage per semaphore - the swapchain image could be not ready yet if the semaphores aren't signaled, #946 is possible related Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Marge Bot <mesa/mesa!3718> Part-of: <mesa/mesa!3718> (cherry picked from commit 1c79afd9)
-
A previous commit ("winsys/svga: Limit the maximum DMA hardware buffer size") made banded DMA transfer kick in when transfering gnome-shell window contents under gnome-shell / wayland. This uncovered a bug where we assumed that banded DMA transfers always occur to the top (y=0) of the surface. Fix this by taking the destination y offset into account. Cc: 19.2 19.3 20.0 <mesa-stable@lists.freedesktop.org> Fixes: 287c94ea ("Squashed commit of the following:") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Tested-by: Marge Bot <mesa/mesa!3733> Part-of: <mesa/mesa!3733> (cherry picked from commit 451cf228)
-
This param is only available starting on kernel 4.1. Use a default value of 0 if it is not found instead. v2: Update commit message (Lionel) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Mark Janes <mark.a.janes@intel.com> Fixes: 96e1c945 ("i965: Move device info initialization to common Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Tested-by: Marge Bot <mesa/mesa!3727> Part-of: <mesa/mesa!3727> (cherry picked from commit 4aa7af9e)
-
Fixes: f0a22956 ("swr/rast: _mm*_undefined_* implementations for gcc<4.9") Fixes: e21fc2c6 ("swr/rast: non-regex knob fallback code for gcc < 4.9") Signed-off-by: Vinson Lee <vlee@freedesktop.org> Reviewed-by: Jan Zielinski <jan.zielinski@intel.com> (cherry picked from commit deb2bbf5)
-
Dylan Baker authored
-
- Feb 06, 2020
-
-
Pierre-Eric Pelloux-Prayer authored
Allocation all the bo as ALWAYS_VALID means they must all fit in memory (vram + gtt) at each command submission. This causes some trouble when the total allocated memory is greater than the available memory. Possible solutions: - being able to tag/untag a bo as ALWAYS_VALID: would require kernel changes - disable VM_ALWAYS_VALID when memory usage is more than a percentage of the available memory - disable VM_ALWAYS_VALID entirely v1 of this patch implemented option 2. v2 (this version) implements option 3. Related issues: - drm/amd#607 - mesa/mesa#1257 It also helps with some piglit tests (-t maxsize -t "max[_-].*size" -t maxuniformblocksize): instead of crashing the machine, the tests fail cleanly. (cherry-pick from ab54624d) Tested-by: Marge Bot <mesa/mesa!3709> Part-of: <mesa/mesa!3709>
-
- Feb 05, 2020
-
-
Tapani Pälli authored
Closes: mesa/mesa#2090 Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Tested-by: Marge Bot <mesa/mesa!3707> Part-of: <mesa/mesa!3707>
-
Tapani Pälli authored
From EXT_disjoint_timer_query spec: "Interaction: This extension adds GetInteger64vEXT if OpenGL ES 3.0 is not supported" See https://github.com/KhronosGroup/OpenGL-Registry/issues/326. Closes: mesa/mesa#2090 Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Part-of: <mesa/mesa!3707>
-
Integer instructions don't coissue. Before e64be391 ("intel/compiler: generalize the combine constants pass"), this pass only looked at float sources. There's no shader-db data in that commit, so I collected some. The results are not good: Haswell total instructions in shared programs: 11898805 -> 11908127 (0.08%) instructions in affected programs: 1218680 -> 1228002 (0.76%) helped: 2 HURT: 5171 helped stats (abs) min: 12 max: 111 x̄: 61.50 x̃: 61 helped stats (rel) min: 1.59% max: 9.20% x̄: 5.40% x̃: 5.40% HURT stats (abs) min: 1 max: 311 x̄: 1.83 x̃: 1 HURT stats (rel) min: 0.02% max: 9.91% x̄: 1.05% x̃: 0.70% 95% mean confidence interval for instructions value: 1.55 2.05 95% mean confidence interval for instructions %-change: 1.02% 1.08% Instructions are HURT. total cycles in shared programs: 221664974 -> 221404750 (-0.12%) cycles in affected programs: 120012620 -> 119752396 (-0.22%) helped: 3464 HURT: 3159 helped stats (abs) min: 1 max: 428160 x̄: 314.55 x̃: 16 helped stats (rel) min: <.01% max: 57.33% x̄: 3.40% x̃: 1.28% HURT stats (abs) min: 1 max: 87846 x̄: 262.54 x̃: 14 HURT stats (rel) min: <.01% max: 85.57% x̄: 3.01% x̃: 0.77% 95% mean confidence interval for cycles value: -224.23 145.65 95% mean confidence interval for cycles %-change: -0.50% -0.19% Inconclusive result (value mean confidence interval includes 0). total spills in shared programs: 9804 -> 10047 (2.48%) spills in affected programs: 6869 -> 7112 (3.54%) helped: 2 HURT: 41 total fills in shared programs: 19863 -> 20319 (2.30%) fills in affected programs: 17428 -> 17884 (2.62%) helped: 2 HURT: 41 LOST: 20 GAINED: 13 This also prevents regressions in "intel/fs: Promote integer constants after lowering integer multiplication" (note: that patch will probably not be committed). When the passes are reorderd, code like mul(8) acc0<1>D g9<8,8,1>D -2078209981D { align1 1Q }; gets turned into mov(1) g23<1>D 2078209981D { align1 WE_all 1N }; ... mul(8) acc0<1>D g13<8,8,1>D -g23<0,1,0>D { align1 1Q compacted }; It's not 100% clear why, but these produce different results. Note that -2078209981 & 0x0ffff = 0x0843, and -(2078209981 & 0x0ffff) = 0xffff0843. It seems like the upper 16-bits of the negation should be ignored. Fixes: e64be391 ("intel/compiler: generalize the combine constants pass") Cc: Iago Toral Quiroga <itoral@igalia.com> Suggested-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Matt Turner <mattst88@gmail.com> The shaders with spills or fills hurt are the usual suspects. A couple compute shaders in Dirt Showdown and a compute shader in Bioshock Infinite. On Haswell, a compute shader (that appears twice in shader-db) from Aztec Ruins was also hurt for spill and fills. Haswell total instructions in shared programs: 11573934 -> 11568335 (-0.05%) instructions in affected programs: 828623 -> 823024 (-0.68%) helped: 2825 HURT: 6 helped stats (abs) min: 1 max: 134 x̄: 2.16 x̃: 1 helped stats (rel) min: 0.02% max: 9.05% x̄: 0.84% x̃: 0.61% HURT stats (abs) min: 1 max: 216 x̄: 81.83 x̃: 56 HURT stats (rel) min: 0.16% max: 8.65% x̄: 4.21% x̃: 4.68% 95% mean confidence interval for instructions value: -2.31 -1.64 95% mean confidence interval for instructions %-change: -0.85% -0.80% Instructions are helped. total cycles in shared programs: 187573593 -> 187004633 (-0.30%) cycles in affected programs: 82816107 -> 82247147 (-0.69%) helped: 2186 HURT: 1741 helped stats (abs) min: 1 max: 35230 x̄: 326.96 x̃: 16 helped stats (rel) min: <.01% max: 46.11% x̄: 3.11% x̃: 0.90% HURT stats (abs) min: 1 max: 6138 x̄: 83.73 x̃: 16 HURT stats (rel) min: <.01% max: 104.11% x̄: 2.73% x̃: 0.75% 95% mean confidence interval for cycles value: -197.13 -92.64 95% mean confidence interval for cycles %-change: -0.72% -0.33% Cycles are helped. total spills in shared programs: 7870 -> 7743 (-1.61%) spills in affected programs: 2260 -> 2133 (-5.62%) helped: 31 HURT: 5 total fills in shared programs: 6320 -> 6263 (-0.90%) fills in affected programs: 3547 -> 3490 (-1.61%) helped: 31 HURT: 6 LOST: 9 GAINED: 9 Ivybridge total instructions in shared programs: 11863372 -> 11859793 (-0.03%) instructions in affected programs: 757183 -> 753604 (-0.47%) helped: 2236 HURT: 3 helped stats (abs) min: 1 max: 81 x̄: 1.86 x̃: 1 helped stats (rel) min: 0.03% max: 5.26% x̄: 0.74% x̃: 0.48% HURT stats (abs) min: 11 max: 301 x̄: 192.33 x̃: 265 HURT stats (rel) min: 1.55% max: 10.51% x̄: 6.89% x̃: 8.62% 95% mean confidence interval for instructions value: -2.01 -1.18 95% mean confidence interval for instructions %-change: -0.77% -0.70% Instructions are helped. total cycles in shared programs: 178377378 -> 177946087 (-0.24%) cycles in affected programs: 76261390 -> 75830099 (-0.57%) helped: 1635 HURT: 1395 helped stats (abs) min: 1 max: 34796 x̄: 333.53 x̃: 16 helped stats (rel) min: <.01% max: 47.15% x̄: 2.82% x̃: 0.64% HURT stats (abs) min: 1 max: 4315 x̄: 81.74 x̃: 18 HURT stats (rel) min: <.01% max: 49.98% x̄: 1.99% x̃: 0.53% 95% mean confidence interval for cycles value: -197.06 -87.62 95% mean confidence interval for cycles %-change: -0.78% -0.43% Cycles are helped. total spills in shared programs: 4188 -> 4182 (-0.14%) spills in affected programs: 1557 -> 1551 (-0.39%) helped: 30 HURT: 3 total fills in shared programs: 5056 -> 5245 (3.74%) fills in affected programs: 2708 -> 2897 (6.98%) helped: 30 HURT: 3 LOST: 5 GAINED: 1 No shader-db changes on any other Intel platform. Tested-by: Marge Bot <mesa/mesa!3544> Part-of: <mesa/mesa!3544> (cherry picked from commit 59488cbb)
-
The extra bits in CB_SHADER_MASK break dual source blending in SkQP on a Stoney device. However: - As far as I can tell, some other dual source blend tests are passing before and after the change. - A hacked around skqp passes on my Vega desktop and Raven laptop - Getting Skqp to give any useful info or to run it outside of Android on ChromeOS is proving difficult. I have confirmed 3 strategies that seem to work: - The old radv behavior of setting CB_SHADER_MASK to 0xF - AMDVLK: CB_SHADER_MASK = 0xFF, and the 3 RB+ regs are 0. - radeonsi: CB_SHADER_MASK = 0xFF, but does not set DISABLE bits in SX_BLEND_OPT_CONTROL for CB 1-7. Let us use the radeonsi solution as that solution also seems like the correct thing to do for holes. I have tested on my Raven laptop that setting the high surfaces to not disabled and downconvert to 32_R does not imply a performance penalty. Fixes: e9316fdf "radv: fix setting CB_SHADER_MASK for dual source blending" Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Tested-by: Marge Bot <mesa/mesa!3670> Part-of: <mesa/mesa!3670> (cherry picked from commit 65a6dc51)
-
Danylo Piliaiev authored
Closes: mesa/mesa#2189 Closes: mesa/mesa#989 Closes: mesa/mesa#2036 CC: <mesa-stable@lists.freedesktop.org> Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com> Reviewed-by: Eric Anholt <eric@anholt.net> Part-of: <mesa/mesa!3216> (cherry picked from commit d83abf1d)
-
Danylo Piliaiev authored
Otherwise there will be a warning: "libEGL warning: FIXME: egl/x11 doesn't support front buffer rendering." Happens with EGL_KHR_surfaceless_context: eglMakeCurrent(egl_display, EGL_NO_SURFACE, EGL_NO_SURFACE, egl_context) eglMakeCurrent(egl_display, egl_surface, egl_surface, egl_context) glFlush() // Here will be a warning Cc: <mesa-stable@lists.freedesktop.org> Closes: mesa/mesa#1525 Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Marge Bot <mesa/mesa!3628> Part-of: <mesa/mesa!3628> (cherry picked from commit 36126b62)
-
Dylan Baker authored
-
Dylan Baker authored
-
- Feb 04, 2020
-
-
Michel Dänzer authored
When a BO or amdgpu_screen_winsys is destroyed. Should fix leaking such BOs in other DRM file descriptions. v2: * Pass the correct file descriptor to drmIoctl (Pierre-Eric Pelloux-Prayer) * Use _mesa_hash_table_remove v3: * Close handles in amdgpu_winsys_unref as well v4: * Adapt to amdgpu_winsys::sws_list_lock. Closes: mesa/mesa#2270 Fixes: 11a3679e "winsys/amdgpu: Make KMS handles valid for original DRM file descriptor" Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (Cherry picked from commit ca6a2230) Tested-by: Marge Bot <mesa/mesa!3693> Part-of: <mesa/mesa!3693>
-
Michel Dänzer authored
Namely, if os_same_file_description determined that the DRM file descriptor references the same file description. v2: * Adapt to amdgpu_winsys::sws_list_lock. v3: * Fix comparison of amdgpu_screen_winsys file descriptions, see mesa/mesa#2413 . * Lock amdgpu_winsys::sws_list_lock for traversing the sws_list in amdgpu_winsys_create. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (Cherry picked from commit 9f2bed49) Part-of: <mesa/mesa!3693>
-
Michel Dänzer authored
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> (Cherry picked from commit f76cbc79) Part-of: <mesa/mesa!3693>
-
Michel Dänzer authored
When the amdgpu_screen_winsys uses the same FD as the amdgpu_winsys (which is always the case for the first amdgpu_screen_winsys), we can just use bo->u.real.kms_handle. v2: * Also only create the kms_handles hash table if the amdgpu_screen_winsys fd is different from the amdgpu_winsys one. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> (Cherry picked from commit c6468f66) Part-of: <mesa/mesa!3693>
-
Michel Dänzer authored
The assumption being that KMS handles are only retrieved for relatively few BOs, so hash tables should be efficient both in terms of performance and memory consumption. We use the address of struct amdgpu_winsys_bo as the key and its kms_handle field (the KMS handle valid for the DRM file descriptor passed to amdgpu_device_initialize) as the hash value. v2: * Add comment above amdgpu_screen_winsys::kms_handles (Pierre-Eric Pelloux-Prayer) v3: * Protect kms_handles hash table with amdgpu_winsys::sws_list_lock mutex. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> (Cherry picked from commit 24075ac6) Part-of: <mesa/mesa!3693>
-
Michel Dänzer authored
v2: * Add dedicated mutex for the list. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> (Cherry picked from commit f4010a6d) Part-of: <mesa/mesa!3693>
-
Destroy rsc->pending_ctx set in etna_resource_destroy(), otherwise the memory is allocated, never free'd, and becomes unreachable. This fixes a memory leak. Fixes: 9e672e4d ("etnaviv: keep references to pending resources") Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Tested-by: Marge Bot <mesa/mesa!3633> Part-of: <mesa/mesa!3633> (cherry picked from commit c32bd325)
-
Jan Vesely authored
Fixes build after llvm 777180a32b61070a10dd330b4f038bf24e916af1 ("[ADT] Make StringRef's std::string conversion operator explicit") CC: <mesa-stable@lists.freedesktop.org> Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> Reviewed-by: Francisco Jerez <currojerez@riseup.net> (cherry picked from commit 0ccda2eb)
-
Dylan Baker authored
-
- Feb 03, 2020
-
-
When the rendering are is not covering the whole FBO, and the biggest damage rect is empty, we can have damage.max{x,y} > damage.min{x,y}, which leads to invalid reload boxes. Fixes: 65ae86b8 ("panfrost: Add support for KHR_partial_update()") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Tested-by: Marge Bot <mesa/mesa!3676> Part-of: <mesa/mesa!3676> (cherry picked from commit b550b7ef)
-
Faith Ekstrand authored
Now that we're using an uncompressed format for the buffer, we have to scale down the dimensions we pass into BLORP when doing buffer->image copies. Fixes: dd92179a "anv: Canonicalize buffer formats for image/buffer..." Closes: #2452 Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Marge Bot <mesa/mesa!3664> Part-of: <mesa/mesa!3664> (cherry picked from commit d7fe9af6)
-
Faith Ekstrand authored
This fixes a hang in the following Vulkan CTS test on TGL-LP: dEQP-VK.descriptor_indexing.storage_buffer_dynamic_in_loop Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Marge Bot <mesa/mesa!3642> Part-of: <mesa/mesa!3642> (cherry picked from commit f93dfb50)
-
Faith Ekstrand authored
Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <mesa/mesa!3454> (cherry picked from commit 9da9abf8)
-
Faith Ekstrand authored
According to the BSpec, this should prevent hangs when using shaders with large URB entries. A more precise fix can be done but it requires re-arranging URB setup. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <mesa/mesa!3454> (cherry picked from commit e1bdb127)
-
Dylan Baker authored
-