| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Someone really needs to look into this.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
Spilling can mess with this considerably.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Midgard prefetches instructions based on tag (ALU, LD/ST, texture *
size). To do so, the shader descriptor specifies the tag of the first
instruction, all instructions specify the tag of the next linear
instruction is, and all branches explicitly specify the tag of the
branch target.
If you mess this up, you get an INSTR_TYPE_MISMATCH, which unambiguously
refers to this problem, but it's still annoying to try to work out all
the branch targets in your head to debug.
Instead, let's track the tags of various blocks over time, so we can
automatically validate tags of branch targets, to make
INSTR_TYPE_MISMATCH issues immediately obvious in a disassembly.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
Fixes: 86786999189c43b4a2c8e1c1a18b55cd2f369fff "aco: implement VGPR spilling"
Reviewed-by: Rhys Perry <[email protected]>
|
|
|
|
|
|
| |
Fixes: 86786999189c43b4a2c8e1c1a18b55cd2f369fff "aco: implement VGPR spilling"
Reviewed-by: Rhys Perry <[email protected]>
|
|
|
|
|
|
| |
Fixes: 86786999189c43b4a2c8e1c1a18b55cd2f369fff "aco: implement VGPR spilling"
Reviewed-by: Rhys Perry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The host query reset entry point didn't use the availability offset
for performance queries.
To fix this, reorder the availability of performance queries to match
other queries.
Signed-off-by: Lionel Landwerlin <[email protected]>
Fixes: 2b5f30b1d9 ("anv: implement VK_INTEL_performance_query")
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Paul Gofman <[email protected]>
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When importing a dmabuf with a specified tiling, the dmabuf user
should always try to set the tiling mode because: 1) the exporter
can set tiling AFTER exporting/importing. 2) a dmabuf could be
exported from a kernel driver other than i915, in this case the
dmabuf user and exporter need to set tiling separately.
This patch fixes a problem when running vkmark under weston with
iris on ICL, it crashed to console with the following assert. i965
doesn't have this problem as it always tries to set the specified
tiling mode.
weston: ../src/gallium/drivers/iris/iris_resource.c:990: iris_resource_from_handle: Assertion `res->bo->tiling_mode == isl_tiling_to_i915_tiling(res->surf.tiling)' failed.
Signed-off-by: James Xiong <[email protected]>
Reviewed-by: Rafael Antognolli <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
In 2ca0d913ea8, we began updating cso_fb->layers to the actual layer
count, rather than 0. This fixed cases where we were setting "Force
Zero RTA Index Enable" even when doing layered rendering. Sadly, it
also broke the check entirely: cso_fb->layers is now 1 for non-layered
cases, but the Force Zero RTA Index check was still comparing for 0.
Fixes: 2ca0d913ea8 ("iris: Fix framebuffer layer count")
|
|
|
|
|
|
|
|
|
|
| |
Python has the identity operator `is`, and the equality operator `==`.
Using `is` with strings sometimes works in CPython due to optimizations
(they have some kind of cache), but it may not always work.
Fixes: 96c4b135e34d0804e41bfbc28fc1b5050c49d71e
("nir/algebraic: Don't put quotes around floating point literals")
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
MALI_DEPTH_TEST should only be set when depth->writemask is true,
not when the depth test is enabled. Let's rename the flag and patch
panfrost_bind_depth_stencil_state() to do the right thing.
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Acked-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
If an app first creates a compute pipeline with
VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT set, then re-compile it
without that flag, the driver should re-compile the compute shader.
Otherwise, it will return the unoptimized one.
Fixes: ce188813bfe ("radv: add initial support for VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT")
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Karol Herbst <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Cc: <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
Bit 13 in aux1 enables dithering
Reviewed-by: Qiang.Yu <[email protected]>
Signed-off-by: Vasily Khoruzhick <[email protected]>
|
|
|
|
| |
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
| |
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
| |
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
| |
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
| |
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Any BO would work, we don't have any BO types yet anyway. Moreover
lima_submit_add_bo() changes BO flags so they won't match allocation
flags.
Reviewed-by: Erico Nunes <[email protected]>
Signed-off-by: Vasily Khoruzhick <[email protected]>
|
|
|
|
|
|
|
| |
Otherwise we may be looking in wrong bucket
Reviewed-by: Erico Nunes <[email protected]>
Signed-off-by: Vasily Khoruzhick <[email protected]>
|
|
|
|
|
|
|
|
| |
LIMA_DEBUG=bocache now activates debug prints for BO allocation,
destruction and BO cache.
Reviewed-by: Erico Nunes <[email protected]>
Signed-off-by: Vasily Khoruzhick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Clearly we do want to have fp16 at some point ... but I kind of give up
debugging and it turns out the issues with fp16 support in 'frost are so
deeply rooted that I might as well disable this non-opt and land
LCRA now.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
| |
The seccomp filter allows read/write, let us make sure nobody can
do anything with this.
Fixes: cff53da3748 "radv: enable secure compile support"
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is incorrect, because polygonMode only applies if the final
primitive type is a polygon; polygonMode doesn't apply to
line-primitives as the comment suggests.
The Vulkan 1.1 spec, section 26.11, "Polygons" defines that polygons are
separate from points and line segments:
" A polygon results from the decomposition of a triangle strip, triangle
fan or a series of independent triangles. Like points and line segments,
polygon rasterization is controlled by several variables in the
VkPipelineRasterizationStateCreateInfo structure. "
Further, section 26.11.2, "Polygon Mode", only define polygonMode to
apply to polygons:
" Possible values of the VkPipelineRasterizationStateCreateInfo::polygonMode
property of the currently active pipeline, specifying the method of
rasterization for polygons, are: "
This seems to clearly define that polygonMode doesn't apply to points
and lines, so let's make sure that we don't early out with the wrong
value.
Signed-off-by: Erik Faye-Lund <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
| |
We don't need it in practice, so this is some more cleanup.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
| |
Rather than having hw-specific swizzles encoded directly in the
instructions, have a unified swizzle arary so we can manipulate swizzles
generically.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want symmetry between loads and stores, so we add a dummy source. So
we get, e.g.
st_int4 _, val, arg_1, arg_2
ld_int4 dest, _, arg_1, arg_2
Semantically, this dummy source represents the data itself, as if the
load is simply a move. That means it has a swizzle that acts as a
source.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
Unused.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function was added in 7e414b58640a to work around a defect in
lower_output_reads(). As of the previous commit no NIR driver calls
lower_output_reads().
This change means we don't need the special GLSL IR style
gl_FragData handling for building the resource list in a NIR based
linker.
No shader-db change on SKL i965.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This will allow us to stop lowering gl_FragData in GLSL IR for NIR
drivers which means we won't need the special GLSL IR type
handling for building the resource list in a NIR based linker.
i965 has been doing this since b828f7a27b2b.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
When doing an indexed draw with index_bias set to a non-zero value (e.g.
by glDrawElementsBaseVertex), the vertex buffer should be offseted by
index_bias vertices.
Add this offset when setting the vertex buffer address.
Signed-off-by: Icenowy Zheng <[email protected]>
Reviewed-by: Vasily Khoruzhick <[email protected]>
|
|
|
|
|
|
|
| |
Now that we're no longer compacting binding table entries, the only time
they can possibly change is when we actually switch subpasses.
Reviewed-by: Rafael Antognolli <[email protected]>
|
|
|
|
|
|
|
|
| |
Instead, always emit one entry for every color attachment in the subpass
or one NULL if there are no color attachments. This will let us adjust
an Ice Lake workaround so we don't get a stall on every draw call.
Reviewed-by: Rafael Antognolli <[email protected]>
|
|
|
|
|
|
|
| |
If it's NULL, we can let the compiler go ahead and delete it or flag it
as NULL.
Reviewed-by: Rafael Antognolli <[email protected]>
|
|
|
|
|
|
|
| |
Also, use color_outputs_valid rather than nr_color_outputs since it
should be a bit more accurate.
Reviewed-by: Rafael Antognolli <[email protected]>
|
|
|
|
|
|
|
|
|
| |
From OES_EGL_image_external_essl3
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1901
Signed-off-by: Yevhenii Kolesnikov <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GKE pool we're using is 1-3 32-core VMs, preemptible (to keep
costs down), with 8 jobs concurrent per system. We have plenty of
memory (4G/core), so we run make -j8 to try to keep the cores busy even
when one job is in a single-threaded step (docker image download, git
clone, artifacts processing, etc.) When all jobs are generating work
for all the cores, they'll be scheduled fairly.
The nodes in the pool have 300GB boot disks (over-provisioned in space
to provide enough iops and throughput) mounted to /ccache, and
CACHE_DIR set pointing to them. This means that once a new
autoscaled-up node has run some jobs, it should have a hot ccache from
then on (instead of having to rely on the docker container cache
having our ccache laying around and not getting wiped out by some
other fd.o job). Local SSDs would provide higher performance, but
unfortunately are not supported with the cluster autoscaler.
For now, the softpipe/llvmpipe test runs are still on the shared
runners, until I can get them ported onto Bas's runner so they can be
parallelized in a single job.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
| |
It was just duplicating the code.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
| |
This effectively reverts MR !2112.
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
That's where `xmlpool_options_h` is defined, and this way we can make sure
nobody starts making use of it in the future :)
Signed-off-by: Eric Engestrom <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
| |
Fixes: a44f5ee0d8b "anv: Rework the internal BO allocation API"
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
| |
When switching this to dynamic state, I forgot that this also needs to
be emitted when we use a polygon-mode set to lines.
Signed-off-by: Erik Faye-Lund <[email protected]>
Fixes: 6d30abb4f14 ("zink: use dynamic state for line-width")
|
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|