summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2017-03-15winsys/amdgpu: reduce max_alloc_size based on GTT limitsNicolai Hähnle1-2/+4
Allocating huge buffers in VRAM is not a problem, but when those buffers start being migrated, the kernel runs into errors because it cannot split those buffer up for moving through GTT. This should fix intermittent failures of GL45-CTS.texture_buffer.texture_buffer_max_size Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 550125e1e73e2441989da11495057a20dd9dad44) [Emil Velikov: resolve trivial conflicts] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Conflicts: src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
2017-03-15gallivm: Override getHostCPUName() "generic" w/ "pwr8" (v4)Ben Crocker1-0/+13
If llvm::sys::getHostCPUName() returns "generic", override it with "pwr8" (on PPC64LE). This is a work-around for a bug in LLVM: a table entry for "POWER8NVL" is missing, resulting in (big-endian) "generic" being returned on little-endian Power8NVL systems. The result is that code that attempts to load the least significant 32 bits of a 64-bit quantity in memory loads the wrong half. This omission should be fixed in the next version of LLVM (4.0), but this work-around should be left in place in case some future version of POWER<n> also ends up unrepresented in LLVM's table. This workaround fixes failures in the Piglit arb_gpu_shader_fp64 conversion tests on POWER8NVL processors. (V4: add similar comment in the code.) Signed-off-by: Ben Crocker <bcrocker@redhat.com> Cc: 12.0 13.0 17.0 <mesa-stable@lists.freedesktop.org> Acked-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit b934aae36410e09892e772b26f61fed5d037fc69)
2017-03-15gallivm: Improve debug output (V2)Ben Crocker2-1/+18
Improve debug output from gallivm_compile_module and lp_build_create_jit_compiler_for_module, printing the -mcpu and -mattr options passed to LLC. V2: enclose MAttrs debug_printf block and llc -mcpu debug_printf in "if (gallivm_debug & <flags>)..." Signed-off-by: Ben Crocker <bcrocker@redhat.com> Cc: 12.0 13.0 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> (v2) [Emil Velikov: rebase] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit a8e9c630f3dc656d107c4252b90c8e991438a3c4)
2017-03-15gallium/u_index_modify: don't add PIPE_TRANSFER_UNSYNCHRONIZED unconditionallyMarek Olšák5-6/+14
It's OK for r300g (because r300g can't write to buffers via the GPU), but not later hardware. This issue was spotted randomly. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit c8ef5123980f9f538c79e626b0092660a2256ae6) (cherry picked from commit bc8d047068df9a2a2281b96ffc53885071a930ae)
2017-03-15gallium/util: remove unused u_index_modify helpersMarek Olšák2-101/+0
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 42297c862f60ccecf794297ee97410f007bd75df)
2017-03-15radeonsi: fix UNSIGNED_BYTE index buffer fallback with non-zero start (v2)Marek Olšák1-2/+2
start can only be non-zero with MultiDrawElements, which is unlikely to occur with UNSIGNED_BYTE indices. v2: Also fix the util_shorten_ubyte_elts_to_userptr call. Tested with the new piglit. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit a264fee6245856340fab9024e1a428626e966335) [Emil Velikov: resolve trivial conflicts] Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Conflicts: src/gallium/drivers/radeonsi/si_state_draw.c
2017-03-15i965/fs: fix uninitialized memory accessLionel Landwerlin1-3/+2
Found while running shader-db under valgrind. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a0ac118398c924f2ae75e5649fbaacd95abd231f)
2017-03-15radv: Never try to create more than max_sets descriptor sets.Bas Nieuwenhuizen2-2/+6
We only use the freed ones after all free space has been used. If the app only allocates small descriptor sets, we might go over max_sets before the memory is full. Signed-off-by: Bas Nieuwenhuizen <basni@google.com> Reviewed-by: Dave Airlie <airlied@redhat.com> CC: <mesa-stable@lists.freedesktop.org> Fixes: f4e499ec79147f4172f3669ae9dafd941aaeeb65 (cherry picked from commit f4487016226c3337fa5fb2244c75ce298093c3ce)
2017-03-15i965/fs: Remove the inline pack_double_2x32 optimizationJason Ekstrand1-29/+0
It's broken in a number of ways. In particular, a bunch of the conditions are backwards so it doesn't actually detect what it's supposed to detect. Since it's been broken, it hasn't actually been helping anything so just deleting it isn't a regression. This (and removing another optimization) were done on master in commit b07381161777ba5d5f4a1d713f7655bcaede4139. Cc: "Kenneth Grunke" <kenneth@whitecape.org> Cc: "Mark Janes" <mark.a.janes@intel.com> [Emil Velikov: patch is a backport of the below "cherry pick"] Fixes: a4393bd97fe ("i965/fs: Fix the inline nir_op_pack_double optimization") (cherry picked from commit b07381161777ba5d5f4a1d713f7655bcaede4139)
2017-03-14anv: wsi: report presentation error per image requestLionel Landwerlin1-8/+15
vkQueuePresentKHR() takes VkPresentInfoKHR pointer and includes a pResults fields which must holds the results of all the images requested to be presented. Currently we're not filling this field. Also as a side effect we probably want to go through all the images rather than stopping on the first error. This commit also makes the QueuePresentKHR() implementation return the first error encountered. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0fcb92c17dee681bd39c08ddf0abc358a27337c7)
2017-03-14anv: fix Get*MemoryRequirements for !LLCConnor Abbott1-6/+8
Even though we supported both coherent and non-coherent memory types, we effectively forced apps to use the coherent types by accident. Found by inspection, only compile tested. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 6319bfc2a6497d708ead536b9a6d5d5a00c1f2f3)
2017-03-14tgsi: fix memory leak in tgsi sanity checkDave Airlie1-3/+5
This just fixes this without repeating the code. Reported-by: Li Qiang Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 69fc7a2c828adbb454072d386a26b568e56dd886)
2017-03-14intel/blorp: Swizzle clear colors on the CPUJason Ekstrand1-18/+30
It's trivial to swizzle clear colors on the CPU, easily deals with the hardware restrictions for render target swizzles, and makes swizzled clears work on all hardware as opposed to just HSW+. Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit e233db6e93e523952577d0314ed68276bda34479)
2017-03-14mesa: Do (TCS && !TES) draw time validation in ES as well.Kenneth Graunke1-19/+26
Now that we have OES_tessellation_shader, the same situation can occur in ES too, not just GL core profile. Having a TCS but no TES may confuse drivers - i965 crashes, for example. This prevents regressions in ES31-CTS.core.tessellation_shader.single.xfb_captures_data_from_correct_stage with some SSO pipeline validation changes I'm making. v2: Add an ES spec citation (suggested by Alejandro) Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> (cherry picked from commit 05a56893aa2570cb1f6e61e3c9cf365266ea1d3a)
2017-03-14st/mesa: don't pass compare mode for stencil-sampled texturesIlia Mirkin1-1/+1
Fixes dEQP-GLES31.functional.stencil_texturing.misc.compare_mode_effect Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 3970257cef5e0c7b5b31c023450f1ea55b784e88)
2017-03-14nvc0: set the render condition in the compute objectIlia Mirkin1-2/+10
Fixes GL45-CTS.compute_shader.conditional-dispatching Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 48f04862c1d74844db9534b32ef73e5a2bc0ae74)
2017-03-14gm107/ir: fix address offset bitfield for ATOMSIlia Mirkin1-1/+1
Fixes GL45-CTS.compute_shader.atomic-case1 on Maxwell Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 7e75f0913ab545be14feb233d1ed74dc48116fb8)
2017-03-14glsl: non-last member unsized array on SSBO must fail compilation on GLSL ES 3.1Jose Maria Casanova Crespo1-4/+7
From GLSL ES 3.10 spec, section 4.1.9 "Arrays": "If an array is declared as the last member of a shader storage block and the size is not specified at compile-time, it is sized at run-time. In all other cases, arrays are sized only at compile-time." In desktop GLSL it is allowed to have unsized-arrays that are not last, as long as we can determine that they are implicitly sized, which is detected at link-time. With this patch Mesa reports a compilation error as glslang does with the following shader: buffer SSBO { vec4 data[]; vec4 moreData;}; void main (void) { } Fixes: dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 5bc222ebafddd14f2329f5096287b51d798a6431)
2017-03-14nvc0/ir: fix ubo max clamp, reset file indexIlia Mirkin1-1/+3
We just increased the max UBO, so we should also increase the clamp that we do for robustness. Similarly, as we're including the fileIndex in the new indirect value, we should reset fileIndex to 0 so that it is not added in a second time. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit c95f821cb4286f8163bfdf341be2b0940011585a)
2017-03-14nvc0/ir: fix robustness guarantees for constbuf loads on kepler+ computeIlia Mirkin1-25/+22
Kepler and up unfortunately only support up to 8 constbufs. We work around this by loading from constbufs as if they were storage buffers. However we were not consistently applying limits to loads from these buffers. Make sure to do the same thing we do for storage buffers. Fixes GL45-CTS.robust_buffer_access_behavior.uniform_buffer Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 1acdd62847cf0da8a8e9c7915d698208d73a5be8)
2017-03-14nvc0: increase number of ubo binding pointsIlia Mirkin1-3/+2
Apparently GL 4.5 requires 14 of these (there's a "*" in the spec, but it's unclear what it refers to). We need to expose an extra binding point for the "program parameters", which means this must be 15. Remove the last vestige of the "use c14 for immediates" idea. Fixes GL45-CTS.shading_language_420pack.binding_uniform_block_array Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 59ca352fc573a37f9f70c1f6217e85dd3e31d38e)
2017-03-14glsl: correct compute shader checks for memoryBarrier functionsMarc Di Luzio1-6/+12
As per the spec - "The functions memoryBarrierShared() and groupMemoryBarrier() are available only in compute shaders; the other functions are available in all shader types." Conform to this by adding another delegate to check for compute shader support instead of only whether the current stage is compute This allows some fragment shaders in Dirt Rally to compile Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 21efe2528cd88cb09ba9f69222f69a8ee47611c9)
2017-03-14i965: Use a better guardband calculation.Jason Ekstrand4-82/+126
(Patch co-authored by Jason and Ken.) We scaled the guardband based on the viewport size, but failed to take into account the translation portion of the viewport transform. This meant the guardband was always centered around the origin. We want it to be centered around the screen-space drawing area, which is the intersection of the viewport and the render target. At best, getting this wrong would reduce the guardband's effectiveness in some cases. At worst, it might break things - objects outside of the guardband are trivially rejected, so getting the guardband in the wrong place and leaving guardband clipping enabled could cause problems. v2: drop clamping of positive maximums. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit f3c068c5c89c8c3dce257ecc2b640f375d3f4836)
2017-03-14i965: Combine the Gen6 SF and Clip viewport atoms.Kenneth Graunke3-57/+30
The next patch will make the guardband calculation dependent on the transformation matrix. Instead of computing it in both atoms, just combine them into a single atom. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> (cherry picked from commit 89ad7f1be6a607b33ffb388516b5d0547b491c33)
2017-03-14radv: pass FMASK alignment to applicationDave Airlie1-0/+1
As was done for dcc and cmask. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 90ac2285f0900972d2a3e7a034b51ee4de374ffb)
2017-03-14radv: Pass DCC alignment to application.Bas Nieuwenhuizen1-0/+1
Signed-off-by: Bas Nieuwenhuizen <basni@google.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Andres Rodriguez <andresx7@gmail.com> (cherry picked from commit 47ca0f537dfbc03f0eb0cb12fdee06dbe664fbc7)
2017-03-14radv: Pass CMASK alignment to application.Bas Nieuwenhuizen1-0/+1
CMASK alignment can be greater than image data alignment, so pass it to the app so that it knows what alignment to backing memory should have. Signed-off-by: Bas Nieuwenhuizen <basni@google.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit eb01b20cc41e9501062eb25034069e484f8b1899)
2017-03-14radv/ac: avoid the fmask path when doing txs.Dave Airlie1-1/+2
This fixes the vulkan samples deferredmultisampling test. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit a864ef7f4824a8319b74d4cf1c82e2dd25672ff1)
2017-03-14dri/common: clear the loaderPrivate pointer in driDestroyDrawableNicolai Hähnle1-0/+12
The GLX specification says about glXDestroyPixmap: "The storage for the GLX pixmap will be freed when it is not current to any client." We're not really following this language to the letter: some of the storage is freed immediately (in particular, the dri3_drawable, which contains both GLXDRIdrawable and loader_dri3_drawable). So we NULL out the pointers to that freed storage; the previous patches added the corresponding NULL-pointer checks. This fixes memory corruption in piglit ./bin/glx-visuals-depth/stencil -pixmap -auto Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 7be0e602ed82d25b9f0db77748618c663d9cbfe7)
2017-03-14glx: guard swap-interval functions against destroyed drawablesNicolai Hähnle2-3/+19
The GLX specification says about glXDestroyPixmap: "The storage for the GLX pixmap will be freed when it is not current to any client." So arguably, functions like glXSwapIntervalMESA can be called after glXDestroyPixmap has been called for the currently bound GLXPixmap. In that case, the GLXDRIDrawable no longer exists, and so we just skip those calls. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit f446f3fb33528eebe9b120340fca3ac5c5ba518d)
2017-03-14glx/dri3: guard in_current_context against a disappeared drawableNicolai Hähnle1-0/+4
Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 21ec35566be2c1aca07083a67f462618ae15fa86)
2017-03-14glx/dri3: handle NULL pointers in loader-to-DRI3 drawable conversionNicolai Hähnle1-0/+2
With a subsequent patch, we might see NULL loaderPrivates, e.g. when a DRIdrawable is flushed whose corresponding GLXDRIdrawable was destroyed. This resulted in a crash, since the loader vs. DRI3 drawable structures have a non-zero offset. Fixes glx-visuals-{depth,stencil} -pixmap Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 40c304fc065259c07c0f4f7a35efedd205e4f250)
2017-03-14radv/ac: correctly size shared memory usage.Dave Airlie1-1/+1
We count the number of slots used, but slots are vec4 sized, so we have to scale by 16 not 4. Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit a1a8aef4c9dbdf254036adada95f0d6e394c5d6a)
2017-03-14winsys/amdgpu: avoid potential segfault in amdgpu_bo_map()Samuel Pitoiset1-7/+10
cs can be NULL when it comes from r600_buffer_map_sync_with_rings() to avoid doing the same checks. It was checked for write mappings but not for read mappings. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit af303abcdbeac3b90fb760de19bed56cc40cfff4)
2017-03-14glsl: fix heap-buffer-overflowBartosz Tomczyk1-1/+1
The `end+1` skips the ']', whereas the `strlen+1` includes the final '\0' in the move to terminate the string. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit fc27181f9e51441a26b7eb4f62794b5e9a994644)
2017-03-14radv/ac: implement txs for buffer textures.Dave Airlie1-0/+5
This fixes a bunch of buffer related: dEQP-VK.memory.pipeline_barrier.* tests, that were crashing in LLVM due to this being missing. Reviewed-by: Andres Rodriguez<andresx7@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 0ecd426490b043aac6a5db0a6e0feaa39f6d9c54)
2017-03-14radv/ac: handle nir irem opcode.Dave Airlie1-0/+3
This fixes: dEQP-VK.spirv_assembly.instruction.compute.opsrem.* Reviewed-by: Andres Rodriguez <andresx7@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org" Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit ecc3fa3ba3967624f67abe8d8188102a08c20d7c)
2017-03-14radv: handle transfer_write as a dst flag.Dave Airlie1-0/+1
It appears we can get image barriers like: srcStageMask: VkPipelineStageFlags = 4096 (VK_PIPELINE_STAGE_TRANSFER_BIT) dstStageMask: VkPipelineStageFlags = 4096 (VK_PIPELINE_STAGE_TRANSFER_BIT) dependencyFlags: VkDependencyFlags = 0 memoryBarrierCount: uint32_t = 0 pMemoryBarriers: const VkMemoryBarrier* = NULL bufferMemoryBarrierCount: uint32_t = 0 pBufferMemoryBarriers: const VkBufferMemoryBarrier* = NULL imageMemoryBarrierCount: uint32_t = 1 pImageMemoryBarriers: const VkImageMemoryBarrier* = 0x7ffc882367b0 pImageMemoryBarriers[0]: const VkImageMemoryBarrier = 0x7ffc882367b0: sType: VkStructureType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER (45) pNext: const void* = NULL srcAccessMask: VkAccessFlags = 4096 (VK_ACCESS_TRANSFER_WRITE_BIT) dstAccessMask: VkAccessFlags = 4096 (VK_ACCESS_TRANSFER_WRITE_BIT) oldLayout: VkImageLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL (7) newLayout: VkImageLayout = VK_IMAGE_LAYOUT_GENERAL (1) srcQueueFamilyIndex: uint32_t = 4294967295 dstQueueFamilyIndex: uint32_t = 4294967295 image: VkImage = 0x2df55e0 subresourceRange: VkImageSubresourceRange = 0x7ffc882367e0: aspectMask: VkImageAspectFlags = 1 (VK_IMAGE_ASPECT_COLOR_BIT) baseMipLevel: uint32_t = 0 levelCount: uint32_t = 1 baseArrayLayer: uint32_t = 0 layerCount: uint32_t = 1 This fixes all the CTS dEQP-VK.memory.pipeline_barrier.transfer_dst tests here, not sure if this is a too large hammer. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit a1c1ba7d5649cca450ca81bf87be36c035a01db0)
2017-03-14radeonsi: don't invoke DCC decompression in update_all_texture_descriptorsMarek Olšák1-5/+6
This fixes a bug uncovered by the 17-part patch series, specifically: "gallium/radeon: merge dirty_fb_counter and dirty_tex_descriptor_counter" If dirty_tex_counter has been updated and set_shader_image invokes DCC decompression, the DCC decompression itself checks the counter and updates descriptors, which in turn invokes the same DCC decompression. The blitter can't handle the recursion and the driver eventually crashes. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit a0740d59aa97a08d89998cb57138e8217a331af6)
2017-03-14i965: Support the force_glsl_version driconf option.Kenneth Graunke2-0/+4
Gallium drivers have had this for a while. It makes sense to support it consistently across drivers, so expose it in i965 as well. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (cherry picked from commit 2f7a7ae13196c58eddea75fc51637f8c2a8579b0)
2017-03-14i965: Fix check for negative pitch in can_do_fast_copy_blit().Kenneth Graunke1-6/+4
At this point, the pitch is in bytes. We haven't yet divided the pitch by 4 for tiled surfaces, so abs(pitch) may be larger than 32K. This means the bit 15 trick won't work. The caller now has signed integers anyway, so just pass those through and do the obvious check. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 02216a1ddf2bcafb86fda352e514f27ab6f7a4fa)
2017-03-14i965: Use a UW source type for CS_OPCODE_CS_TERMINATE.Kenneth Graunke1-1/+1
SIMD16 compute shaders use a send(16) with mlen 1 for the EOT message, using a source of g127 for the single register. With a UD type, this supposedly could read g128, which doesn't exist, causing the simulator to get cranky. Use a UW type to avoid this. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (cherry picked from commit fcf723b647f36fa174d29b1fe6a9732637a1f8d1)
2017-03-14i965: Fix fast depth clears for surfaces with a dimension of 16384.Kenneth Graunke1-0/+12
I hadn't bothered to set this bit because I figured it would just paper over us getting the rectangle wrong. But it turns out that there is a legitimate reason to use it, so let's do so. The alternative would be to chop up 16k clears to multiple 8k clears, which is pointlessly painful. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Nanley Chery <nanley.g.chery@intel.com> (cherry picked from commit 5106df85da20d57007e89262472bb1624afbdaba)
2017-03-14radv: program a default point size.Dave Airlie1-1/+2
Along the lines of what 3b804819 anv: Default PointSize to 1.0 if not written by the shader does for anv, program a default point size in the hw of 1.0. This preempt fixes a bunch of geom shader tests. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 2ab2be092d15ddb449b4a215609705bae68089a0)
2017-03-14st/mesa: destroy pipe_context before destroying st_context (v2)Marek Olšák1-6/+7
If radeonsi starts compiling an optimized shader variant asynchronously with a GL debug callback set and the application destroys the GL context, radeonsi crashes when trying to write shader stats into the debug output of a non-existent context after compilation, because st/mesa was destroyed before pipe_context. Firefox with WebGL2 enabled hits this bug. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99456 v2: protect against a double destroy in st_create_context_priv and callers. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit d9ef54923804d5fe44a1d3ad5c29e9b8e8382359)
2017-03-14mesa: Don't advertise GL_OES_read_format in core profileIan Romanick1-1/+1
OpenGL ES implementations are not allowed to ship ARB extensions, and OpenGL implementations are not allowed to ship OES extensions. The functionality is also included in GL_ARB_ES2_compatibility. Ever OpenGL core-profile driver currently exposes both extensions. I don't know of any applications that explicitly check for GL_OES_read_format, so removing it seems very unlikely to cause problems. No functionality is removed. I have left this extension in place for compatibility profile. There are still OpenGL 1.x drivers in Mesa, and adding code to check for compatibility profile and not GL_ARB_ES2_compatibility for GL_IMPLEMENTATION_COLOR_READ_TYPE and GL_IMPLEMENTATION_COLOR_READ_FORMAT just feels dumb. Three other other alternatives considered: - Remove the string from compatibility profile drivers but leave the functionality in place. - Add a flag to expose the extension string, and set it in every OpenGL driver that does not expose GL_ARB_ES2_compatibility (and those drivers only). I tried this. You can't have two instances of an extension in the extension table (one dummy_true for ES1 and one with a flag for compatibility profile), so the implementation requires a bit of effort. - Only expose the extension in compatibility if the version is less than 2.0. I didn't see an easy way to do this. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit c4a0c1efff77ed90dfebf969348cd440195ae38a)
2017-03-14swr: Align query results allocationGeorge Kyriazis2-4/+5
Some query results struct contents are declared as cache line aligned. Use aligned malloc, and align the whole struct, to be safe. Fixes crash when compiling with clang. CC: <mesa-stable@lists.freedesktop.org> Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com> (cherry picked from commit 00847e4f14dd237dfcdb2c3d15be1325a08ccf5a)
2017-03-14swr: Prune empty nodes in CalculateProcessorTopology.Bruce Cherniak1-0/+9
CalculateProcessorTopology tries to figure out system topology by parsing /proc/cpuinfo to determine the number of threads, cores, and NUMA nodes. There are some architectures where the "physical id" begins with 1 rather than 0, which was creating and empty "0" node and causing a crash in CreateThreadPool. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97102 Reviewed-By: George Kyriazis <george.kyriazis@intel.com> CC: <mesa-stable@lists.freedesktop.org> (cherry picked from commit b829206b0739925501bcc68233437d6d03b79795)
2017-03-14glsl: split DIV_TO_MUL_RCP into single- and double-precision flagsNicolai Hähnle2-9/+14
Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Tested-by: Glenn Kennard <glenn.kennard@gmail.com> Tested-by: James Harvey <lothmordor@gmail.com> Cc: 17.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit b71c415c3d288da4b5f533ece42f50f4f20a8c33)
2017-03-13spirv: don't assert with location decorations on non i/o variablesLionel Landwerlin1-1/+2
Some applications might add location decoration to samplers. Rather than raising an error it seems it would make more sense to just discard these decorations. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: 17.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 8a28e764d0e28d0d4dfa3b81b89fa3baf30e94f2)
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 03:51:08 +0000