- Feb 06, 2017
-
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.velikov@collabora.com>
-
- Feb 03, 2017
-
-
This fixes a vertex data corruption issue if some of the vertex streams go through the MMU and some don't. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Tested-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by:
Christian Gmeiner <christian.gmeiner@gmail.com> (cherry picked from commit e158b749) Nominated-by:
Christian Gmeiner <christian.gmeiner@gmail.com>
-
This fixes "st/va: delay calling begin_frame until we have all parameters". v2: call begin frame after decoder (re)creation as well. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Nayan Deshmukh <nayan26deshmukh@gmail.com> Tested-by:
Andy Furniss <adf.lists@gmail.com> (cherry picked from commit 1338d912)
-
PresentPixmap only works if the pixmap depth matches with the window depth, otherwise it returns a BadMatch protocol error. Even if the depths match, the result won't look correctly if the VDPAU RGB component order doesn't match the X11 one so we only allow the X11 format. For other buffers we copy them to a buffer which is send to X. v2: only send buffers with format VDP_RGBA_FORMAT_B8G8R8A8 v3: reword commit message v4: add comment explaining the code Signed-off-by:
Nayan Deshmukh <nayan26deshmukh@gmail.com> Reviewed-by:
Christian König <christian.koenig@amd.com> (cherry picked from commit 31908d6a) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99637 Nominated-by:
Nayan Deshmukh <nayan26deshmukh@gmail.com> Nominated-by: Michel Dänzer <michel.daenzer@amd.com> (IRC)
-
These changes set the correct llvm version and elf include path which differ for Marshmallow and Nougat Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 9c45bb73) [Emil Velikov: resolve trivial conflicts] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: Android.common.mk
-
It is not clear from the docs exactly how pipelined STATE_BASE_ADDRESS actually is. We know from experimentation that we need to flush the render cache prior to emitting STATE_BASE_ADDRESS and invalidate the texture cache afterwards. The only thing the PRM says is that, on gen8+ we're supposed to invalidate the state cache after STATE_BASE_ADDRESS but experimentation has indicated that doing so does nothing whatsoever. Since we don't really know, let's do just a bit more flushing in the hopes that this won't be a problem again. In particular: 1) Do a CS stall before we emit STATE_BASE_ADDRESS since we don't really know whether or not it's pipelined. 2) Do a data cache flush in case what runs before STATE_BASE_ADDRESS is a compute shader. 3) Invalidate the state and constant caches after STATE_BASE_ADDRESS because the state may be getting cached there (we don't really know). Reported-by:
Mark Janes <mark.a.janes@intel.com> Tested-by:
Mark Janes <mark.a.janes@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 92128590)
-
We had no good reason for *not* doing this on gen7 before but we didn't know it was needed. Recently, when trying update to Vulkan CTS version 1.0.2 in our CI system, Mark discovered GPU hangs on Haswell that appear to be STATE_BASE_ADDRESS related. This commit fixes them. Reported-by:
Mark Janes <mark.a.janes@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit f1f97941)
-
This causes hangs on Broadwell if you try to render to it. I have no idea how we managed to not hit this earlier. Tested-by:
Mark Janes <mark.a.janes@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 48719304)
-
Tested-by:
Mark Janes <mark.a.janes@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a0348b5a)
-
This fixes rendering of full-screen quads (and other screen-filling geometry, e.g. ioquake3 walls up-close) on gc3000. It should be a no-op on other hardware. - It looks like SE_CLIP registers were not set at all. I'm amazed that rendering worked without them. Emit them to avoid issues on gc3000. - Define constants ETNA_SE_SCISSOR_MARGIN_RIGHT (0x1119) ETNA_SE_SCISSOR_MARGIN_BOTTOM (0x1111) ETNA_SE_CLIP_MARGIN_RIGHT (0xffff) ETNA_SE_CLIP_MARGIN_BOTTOM (0xffff) These demarcate the margin (fixp16) between the computed sizes and the value sent to the chip. I have set these to the numbers used by the Vivante driver for gc2000. I am not sure whether any old hardware was relying on the old numbers, or whether those were just a guess. But if so, these need to be moved to the _specs structure. CC: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Wladimir J. van der Laan <laanwj@gmail.com> Acked-by:
Christian Gmeiner <christian.gmeiner@gmail.com> (cherry picked from commit 56314f5b)
-
Shaders using sin/cos instructions were not working on GC3000. The reason for this turns out to be that these chips implement sin/cos in a different way (but using the same opcodes): - Need their input scaled by 1/pi instead of 2/pi. - Output an x and y component, which need to be multiplied to get the result. - tex_amode needs to be set to 1. Add a new bit to the compiler specs and generate these instructions as necessary. CC: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Wladimir J. van der Laan <laanwj@gmail.com> Acked-by:
Christian Gmeiner <christian.gmeiner@gmail.com> (cherry picked from commit fe3bb8cd)
-
Commit 2852efcd moved the location of the depth input attachment surface state from the render pass to the image view, but failed to update the surface state location used when emitting the binding table. Fix this by loading the surface state from the correct location. Fixes: dEQP-VK.renderpass.formats.d16_unorm.input.* dEQP-VK.renderpass.formats.d24_unorm_s8_uint.input.* dEQP-VK.renderpass.formats.d32_sfloat.input.* dEQP-VK.renderpass.formats.x8_d24_unorm_pack32.input.* dEQP-VK.renderpass.attachment_allocation.input_output.93 dEQP-VK.renderpass.attachment_allocation.input_output.92 dEQP-VK.renderpass.attachment_allocation.input_output.82 dEQP-VK.renderpass.attachment_allocation.input_output.46 Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Iago Toral Quiroga <itoral@igalia.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> (cherry picked from commit 33e0c5d0)
-
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 fc27181f)
-
Exposing rb swapped (or other swizzled) formats for rendering would involve swizzing in the pixel shader. This is not the case at the moment, so reject requests for creating such surfaces. (GPUs that need an extra resolve step anyway due to multiple pixel pipes, such as gc2000, might also do this swap in the resolve operation. But this would be tricky to keep track of) CC: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Wladimir J. van der Laan <laanwj@gmail.com> Acked-by:
Christian Gmeiner <christian.gmeiner@gmail.com> (cherry picked from commit 65856894)
-
Use of unsigned loop control variable with '>= 0' would lead to infinite loop. Reported by clang: etnaviv_compiler.c:1024:39: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare] for (unsigned sp = c->frame_sp; sp >= 0; sp--) ~~ ^ ~ v2: Simply use the same datatype as c->frame_sp is using. CC: <mesa-stable@lists.freedesktop.org> Reported-by:
Rhys Kidd <rhyskidd@gmail.com> Signed-off-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by:
Rhys Kidd <rhyskidd@gmail.com> (cherry picked from commit 82fe240a)
-
Fixes: dEQP-VK.glsl.texture_functions.texture.*1darray* 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 8477aa71)
-
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 0ecd4264)
-
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 ecc3fa3b)
-
We weren't adding the fragment position properly. 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 059dd171)
-
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 a1c1ba7d)
-
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 a0740d59)
-
Commit 7b5878ee increased number of outputs to 64, but left output array intact. This caused stack overflow when number of outputs is bigger then 32. Found by ASAN. Cc: "12.0 13.0 17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit a41f2527)
-
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 2f7a7ae1)
-
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 02216a1d)
-
Applications may delete a shader program, create a new one, and bind it before the next draw. With terrible luck, malloc may randomly return a chunk of memory for the new gl_program that happened to be the exact same pointer as our previously bound gl_program. In this case, our logic to detect new programs in brw_upload_pipeline_state() would break: if (brw->vertex_program != ctx->VertexProgram._Current) { brw->vertex_program = ctx->VertexProgram._Current; brw->ctx.NewDriverState |= BRW_NEW_VERTEX_PROGRAM; } Because the pointer is the same, we'd think it was the same program. But it could be wildly different - a different stage altogether, different sets of resources, and so on. This causes utter chaos. As unlikely as this seems, I believe I hit this when running a subset of the CTS in a loop, in a group of tests that churns through simple programs, deleting and rebuilding them. Presumably malloc uses a bucketing cache of sorts, and so freeing up a gl_program and allocating a new one fairly quickly causes it to reuse that memory. The result was that brw->vertex_program->info.num_ssbos claimed the program had SSBOs, while brw->vs.base.prog_data.binding_table claimed that there were none. This was crazy, because the binding table is calculated from info.num_ssbos - the shader info appeared to change between shader compile time and draw time. Careful use of watchpoints revealed that it was being clobbered by rzalloc's memset when building an entirely different program... Fortunately, our 0xd0d0d0d0 canary for unused binding table entries caused us to crash out of bounds when trying to upload SSBOs, or we may have never discovered this heisenbug. Fixes crashes in GL45-CTS.compute_shader.sso-case2 when using a hacked cts-runner that only runs GL45-CTS.compute_shader.s* in EGL config ID 5 at 64x64 in a loop with 100 iterations. Cc: "17.0 13.0 12.0" <mesa-stable@lists.freedesktop.org> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Timothy Arceri <timothy.arceri@collabora.com> Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 7c5629a2)
-
Apparently the source is not an address but an offset, so we actually need to use the base. Signed-off-by:
Bas Nieuwenhuizen <basni@google.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> CC: <mesa-stable@lists.freedesktop.org> (cherry picked from commit 96c60b7f)
-
Emil Velikov authored
Analogous to what we do for the dri and gallium drivers. Cc: 17.0 13.0 <mesa-stable@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@colllabora.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit cb6be5c8)
-
Emil Velikov authored
These files belong to the vulkan loader. Identical to 045f38a5 vulkan: Don't install vk_platform.h or vulkan.h. Cc: Dave Airlie <airlied@redhat.com> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: 17.0 <mesa-stable@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Matt Turner <mattst88@gmail.com> (cherry picked from commit 6f2dec0a)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 091f2b8c)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 6ba96bdc)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit ede4ff9a)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 5a0ba1e5)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit ee5de932)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit af860850)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Cc: Jon Turney <jon.turney@dronecode.org.uk> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 912b4f54)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Cc: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Jeremy Sequoia <jeremyhu@apple.com> (cherry picked from commit 5b874cee)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit d66f9e6d)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Cc: Axel Davy <axel.davy@ens.fr> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit d221bf9b)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 517f34b4)
-
Emil Velikov authored
Analogous to previous commit. Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org> Cc: Aaron Watry <awatry@gmail.com> Cc: Francisco Jerez <currojerez@riseup.net> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 65d5a60c)
-