- Jan 30, 2020
-
-
Brian Ho authored
Previously, calling vkCmdCopyQueryPoolResults with the VK_QUERY_RESULT_WITH_AVAILABILITY_BIT flag set the query result field in the buffer to 0 if unavailable and the query result if available. This was a misunderstanding of the Vulkan spec, and this commit corrects the behavior to emitting a separate available result in addition to the query result. Tested-by: Marge Bot <mesa/mesa!3560> Part-of: <mesa/mesa!3560>
-
Brian Ho authored
Previously, calling vkGetQueryPoolResults with the VK_QUERY_RESULT_WITH_AVAILABILITY_BIT flag set the query result field in *pData to 0 if unavailable and the query result if available. This was a misunderstanding of the Vulkan spec, and this commit corrects the behavior to eriting a separate available result in addition to the query result. Part-of: <mesa/mesa!3560>
-
Brian Ho authored
Fixes a leak from freeing event but not event->bo. Reviewed-by: Jonathan Marek <jonathan@marek.ca> Tested-by: Marge Bot <mesa/mesa!3639> Part-of: <mesa/mesa!3639>
-
Kenneth Graunke authored
This is strdup'd, it needs to be freed. CID: 1458032 Fixes: f93bb2fb ("loader: Check if the kernel driver is i915 before loading iris") Reviewed-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com> Tested-by: Marge Bot <mesa/mesa!3630> Part-of: <mesa/mesa!3630>
-
Jan Zielinski authored
Update features.txt to reflect ARB_tessellation_shader support in SWR Reviewed-by: Krzysztof Raszkowski <krzysztof.raszkowski@intel.com> Tested-by: Marge Bot <mesa/mesa!3636> Part-of: <mesa/mesa!3636>
-
Kenneth Graunke authored
If the batch references the buffer, we will have to flush the batch immediately before mapping it, at which point it will be busy. (This bug has existed for a long time...even going back to BLT-era...) Fixes: 77992319 ("i965/tex_image: Use meta for instead of the blitter PBO TexImage and GetTexImage") Fixes: d5d4ba91 ("i965/tex_subimage: use meta instead of the blitter for PBO TexSubImage") Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Marge Bot <mesa/mesa!3616> Part-of: <mesa/mesa!3616>
-
Christian Gmeiner authored
These are the ETNAVIV_PARAM's returned from a GC400 found on a STM32MP157C-DK2 Discovery Board running mainline kernel. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Tested-by: Marge Bot <mesa/mesa!3195> Part-of: <mesa/mesa!3195>
-
Qiang Yu authored
Disable using heap buffer when set. Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Tested-by: Marge Bot <mesa/mesa!3264> Part-of: <mesa/mesa!3264>
-
Qiang Yu authored
Newly added heap buffer create interface can create a large enough buffer whose backup memory can increase dynamically as needed. Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Andreas Baierl <ichgeh@imkreisrum.de> Signed-off-by: Qiang Yu <yuq825@gmail.com> Part-of: <mesa/mesa!3264>
-
Qiang Yu authored
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Andreas Baierl <ichgeh@imkreisrum.de> Signed-off-by: Qiang Yu <yuq825@gmail.com> Part-of: <!3264>
-
- Jan 29, 2020
-
-
Icenowy Zheng authored
When setting the vertex buffers, lima calls util_set_vertex_buffers_mask() to reference and copy buffers. That function function adds dst with start_slot internally, so lima should not offset the destination address again. This is discovered when comparing with other drivers, and fixed by removing the extra offset in lima_set_vertex_buffers(). This fixes draws that get translated in u_vbuf, because u_vbuf adds extra vertex buffers when translating. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Marge Bot <mesa/mesa!3620> Part-of: <mesa/mesa!3620>
-
Jonathan Marek authored
Gets some basic tests under "dEQP-VK.synchronization.*event*" passing Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Tested-by: Marge Bot <mesa/mesa!3123> Part-of: <mesa/mesa!3123>
-
Christian Gmeiner authored
It gets emitted when needed. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Jonathan Marek <jonathan@marek.ca> Tested-by: Marge Bot <mesa/mesa!3631> Part-of: <mesa/mesa!3631>
-
Daniel Schürmann authored
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Tested-by: Marge Bot <mesa/mesa!3627> Part-of: <mesa/mesa!3627>
-
Samuel Pitoiset authored
Based on ANV. This removes a bunch of duplicated code for properties. Fixes: 1b8d99e2 ("radv: bump conformance version to 1.2.0.0") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Tested-by: Marge Bot <mesa/mesa!3626> Part-of: <mesa/mesa!3626>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Marge Bot <mesa/mesa!3503> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
The gmem state is split out now, so it does not require synchronization. But gmem rendering still accesses vsc state from the context. TODO maybe there is a better way? For gen's that don't do vsc resizing, this is probably easier.. but for a6xx there isn't really a great position for more fine grained locking. Maybe it doesn't matter since in practice the lock shouldn't be contended. Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Which also has the benefit of getting rid of fd_context::gmem. Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Prep work to reduce churn in next patch. Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
In a following patch, when we cache the gmem state, we will want to treat the gmem state as immuatable. So start converting things to const to make this more clear.. fd_tile is a good place to start. Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
The tile and vsc_pipe arrays are really part of the GMEM configuration. So pull these out of fd_context and into fd_gmem_stateobj. Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Rob Clark authored
Prep work for reorganizing GMEM state and extracting out of fd_context. The vsc pipe bo was the one thing that doesn't change with GMEM/tile config. Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <mesa/mesa!3503>
-
Alejandro Piñeiro authored
It was only used to be initialized to zero. Not even updated as descriptor sets are bind. As far as I understand, setting the bit TU_CMD_DIRTY_DESCRIPTOR_SET on tu_cmd_state.dirty is used instead. Reviewed-by: Jonathan Marek <jonathan@marek.ca> Tested-by: Marge Bot <mesa/mesa!3624> Part-of: <mesa/mesa!3624>
-
Timur Kristóf authored
Previously, is_atomic really meant "is not atomic", contrary to its name. This commit fixes it to mean what one would think it means. Fixes: 69bed1c9 Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Tested-by: Marge Bot <mesa/mesa!3618> Part-of: <mesa/mesa!3618>
-
Kenneth Graunke authored
There was never much point in artificially limiting chaining to two batches - we can trivially support arbitrary length chains. Currently, we should only ever have 1 or 2, but this may change. Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Tested-by: Marge Bot <mesa/mesa!3613> Part-of: <mesa/mesa!3613>
-
Kenneth Graunke authored
No need to pass it, we can just use batch->screen->devinfo. Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Part-of: <mesa/mesa!3613>
-
Kenneth Graunke authored
For the moment, everything is I915_EXEC_RENDER, so this isn't necessary. But even should that change, I don't think we want to handle multiple engines in this manner. Nowadays, we have batch->name (IRIS_BATCH_RENDER, IRIS_BATCH_COMPUTE, possibly an IRIS_BATCH_BLIT for blorp batches someday), which describes the functional usage of the batch. We can simply check that and select an engine for that class of work (assuming there ever is more than one). Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Part-of: <mesa/mesa!3613>
-
Emma Anholt authored
This fixes a regression in "vkcube -m headless" rendering, but upsettingly none of my CTS tests I've been using. Fixes: 59f29fc8 ("turnip: Convert the rest of tu_cmd_buffer.c over to the new pack macros.") Caught-by: Jonathan Marek <jonathan@marek.ca> Tested-by: Marge Bot <mesa/mesa!3609> Part-of: <mesa/mesa!3609>
-
Brian Ho authored
This commit enables the occlusionQueryPrecise feature. No additonal work is required as occlusion queries are already implemented to track exact sample counts. Also enables a number of extra tests on the Vulkan CTS. Tested-by: Marge Bot <mesa/mesa!3605> Part-of: <mesa/mesa!3605>
-
Daniel Schürmann authored
This patch has a slight effect on pipelinedb: Totals from affected shaders: SGPRS: 23616 -> 21504 (-8.94 %) VGPRS: 15088 -> 14444 (-4.27 %) Spilled SGPRs: 0 -> 0 (0.00 %) Spilled VGPRs: 0 -> 0 (0.00 %) Private memory VGPRs: 0 -> 0 (0.00 %) Scratch size: 0 -> 0 (0.00 %) dwords per thread Code Size: 662660 -> 664600 (0.29 %) bytes LDS: 49 -> 49 (0.00 %) blocks Max Waves: 3079 -> 3204 (4.06 %) Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Tested-by: Marge Bot <!3602> Part-of: <!3602>
-
Daniel Schürmann authored
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Part-of: <mesa/mesa!3602>
-
Daniel Schürmann authored
This patch fixes register allocation if multiple live-range splits occur to the same variable within one instruction. Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Part-of: <mesa/mesa!3602>
-
Daniel Schürmann authored
For all VMEM instructions, the resource constant is now in operands[0]. For MIMG instructions, the sampler shares operands[1] with write data in case this instruction writes memory. Moving the VADDR to be the last operand for MIMG is the first step to support Navi NSA encoding. Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Part-of: <mesa/mesa!3602>
-
Caio Oliveira authored
In a NIR generated using SPIR-V initializers to variables, copy propagation can end up transforming vec1 32 ssa_33 = deref_var &@1 (shared mat2x4) vec1 32 ssa_35 = mov ssa_33 vec1 32 ssa_7 = deref_cast (mat2x4 *)ssa_35 (shared mat2x4) /* ptr_stride=0 */ into vec1 32 ssa_33 = deref_var &@1 (shared mat2x4) vec1 32 ssa_7 = deref_cast (mat2x4 *)ssa_33 (shared mat2x4) /* ptr_stride=0 */ Before the optimization, the "head" of a path of deref that uses ssa_7 will be the cast. After, it will be the variable in ssa_33. Since the types are the same, this is a trivial cast that would be picked up by nir_opt_deref. If we need to compare such deref-chain after optimization with another deref-chain for the same variable, the compare function will get confused by the cast in the middle. One alternative would be to add nir_opt_deref to places that compare derefs, but that might not scale well, so skip the trivial casts when generating the paths instead. Motivated by the discussion in mesa/mesa!3047 (comment 383660) . Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Marge Bot <mesa/mesa!3420> Part-of: <mesa/mesa!3420>
-