- Feb 13, 2019
-
-
Dylan Baker authored
-
- Feb 12, 2019
-
-
This can happen when we record a VkCmdDraw in a secondary buffer that was created inheriting from the primary buffer, but with the framebuffer set to NULL in the VkCommandBufferInheritanceInfo. Vulkan 1.1.81 spec says that "the application must ensure (using scissor if neccesary) that all rendering is contained in the render area [...] [which] must be contained within the framebuffer dimesions". While this should be done by the application, commit 465e5a86 added the clamp to the framebuffer size, in case of application does not do it. But this requires to know the framebuffer dimensions. If we do not have a framebuffer at that moment, the best compromise we can do is to just apply the scissor as it is, and let the application to ensure the rendering is contained in the render area. v2: do not clamp to framebuffer if there isn't a framebuffer v3 (Jason): - clamp earlier in the conditional - clamp to render area if command buffer is primary v4: clamp also x and y to render area (Jason) v5: rename used variables (Jason) Fixes: 465e5a86 ("anv: Clamp scissors to the framebuffer boundary") CC: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 1ad26f94)
-
This fixes a critical issue. Cc: <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109575 Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 1b8983c2)
-
"The C standard says that compound literals which occur inside of the body of a function have automatic storage duration associated with the enclosing block. Older GCC releases were putting such compound literals into the scope of the whole function, so their lifetime actually ended at the end of containing function. This has been fixed in GCC 9. Code that relied on this extended lifetime needs to be fixed, move the compound literals to whatever scope they need to accessible in." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109543 Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Gustaw Smolarczyk <wielkiegie@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 129a9f49)
-
Piglit's vp-max-array test creates a vertex program containing a uniform array sized to the value of GL_MAX_NATIVE_PROGRAM_PARAMETERS_ARB. Mesa will then add additional state-var parameters for things like the MVP matrix. radeonsi currently exposes a value of 4096, derived from constant buffer upload size. This means the array will have 4096 elements, and the extra MVP state-vars would get a prog_src_register::Index of over 4096. Unfortunately, prog_src_register::Index is a signed 13-bit integer, so values beyond 4096 end up turning into negative numbers. Negative source indexes are only valid for relative addressing, so this ends up generating illegal IR. In prog_to_nir, this would cause an out of bounds array access. st_mesa_to_tgsi checks for a negative value, assumes it's bogus, and remaps it to parameter 0 in order to get something in-range. This isn't right - instead of reading the MVP matrix, it would read the first element of the vertex program's large array. But the test only checks that the program compiles, so we never noticed that it was broken. This patch limits the size of the program limits, with the understanding that we may need to generate additional state-vars internally. i965 has exposed 1024 for this limit for years, so I don't expect lowering it to 2048 will cause any practical problems for radeonsi or other drivers. Fixes vp-max-array with prog_to_nir.c. Cc: "19.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit f45dd6d3)
-
If there is no information about number of render targets Signed-off-by:
Leo Liu <leo.liu@amd.com> Reviewed-by:
Boyuan Zhang <boyuan.zhang@amd.com> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit a0a52a03)
-
Add "PIPE_VIDEO_PROFILE_MAX" to enum, so it will make sure here will be correct when adding more profiles in the future. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109107 Signed-off-by:
Leo Liu <leo.liu@amd.com> Reviewed-by:
Boyuan Zhang <boyuan.zhang@amd.com> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 21cdb828)
-
Marek Olšák authored
wow, it's hard to believe that fence and syncobjs dependencies were ignored. Cc: 18.3 19.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit ddfe209a)
-
Marek Olšák authored
Cc: 18.3 19.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 61c678d4)
-
Marek Olšák authored
Cc: 18.3 19.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 4522f01d)
-
For some reason we don't use view volume clipping by default, and use scissors instead. These scissors were set to an 8k max fb size, while the driver advertises 16k-sized framebuffers. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit cc79a148)
-
If the driver does not support rendering to these formats but does support texturing, we can end up in incompatibilities between textures and renderbuffers that are then copied to. Fixes KHR-GL45.copy_image.functional on nvc0 Reviewed-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit cbd1ad61)
-
Karol Herbst authored
Some NVIDIA hardware can accept 128 fragment shader input components, but only have up to 124 varying-interpolated input components. We add a new cap to express this cleanly. For most drivers, this will have the same value as PIPE_SHADER_CAP_MAX_INPUTS for the fragment shader. Fixes KHR-GL45.limits.max_fragment_input_components Conflicts resolved by Dylan Signed-off-by:
Karol Herbst <karolherbst@gmail.com> [imirkin: rebased, improved docs/commit message] Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Acked-by:
Rob Clark <robdclark@gmail.com> Acked-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 6010d7b8)
-
Acked-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit cce49557)
-
Acked-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 815a8e59)
-
Karol Herbst authored
[imirkin: add a few more "long" prefixes to safen things up] Acked-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 12669d29)
-
v2: (Karol Herbst <kherbst@redhat.com> * fix Value setup for the builtins Signed-off-by:
Boyan Ding <boyan.j.ding@gmail.com> [imirkin: track the fp64 flag when switching ops to calls] Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 656ad060)
-
Signed-off-by:
Boyan Ding <boyan.j.ding@gmail.com> Acked-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 79374080)
-
Signed-off-by:
Boyan Ding <boyan.j.ding@gmail.com> Acked-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 04593d9a)
-
Not quite perfect, but at least we don't end up with random values in the query buffer. Fixes KHR-GL45.pipeline_statistics_query_tests_ARB.functional_default_qo_values Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 6adb9b38)
-
For the NO_WAIT variants, we would jump into the ALWAYS case for both nested and inverted occlusion queries. However if the query had previously completed, the application could reasonably expect that the render condition would follow that result. To resolve this, we remove the nesting distinction which unnecessarily created an imbalance between the regular and inverted cases (since there's no "zero" condition mode). We also use the proper comparison if we know that the query has completed (which could happen as a result of an earlier get_query_result call). Fixes KHR-GL45.conditional_render_inverted.functional Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit e00799d3)
-
Looks like SUBFM.3D and SUEAU are perfectly capable of dealing with 3d tiling, they just need the correct inputs. Supply them. We also have to deal with the case where a 2d "layer" of a 3d image is bound. In this case, we supply the z coordinate separately to the shader, which has to optionally treat every 2d case as if it could be a slice of a 3d texture. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 162352e6)
-
Atomic operations don't update the local cache, which means that we would have to issue CCTL operations in order to get the updated values. When we know that a buffer is primarily used for atomic operations, it's easier to just avoid the caching at that level entirely. The same issue persists for non-atomic buffers, which will have to be fixed separately. Fixes the failing dEQP-GLES31.functional.atomic_counter.* tests. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 4443b6dd)
-
The hardware does not natively support FIXED and DOUBLE formats. If those are used in an indirect draw, they have to be converted. Our conversion tries to be clever about only converting the data that's needed. However for indirect, that won't work. Given that DOUBLE or FIXED are highly unlikely to ever be used with indirect draws, read the indirect buffer on the CPU and issue draws directly. Fixes the failing dEQP-GLES31.functional.draw_indirect.random.* tests. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 399215eb)
-
The check was for 1 bit being set, which is clearly not what we want. CC: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 3c24fc64)
-
Equivalent of ANV patch c7f4a286 CC: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 39ab4e12)
-
When Mesa is compiled for gallium-xlib using e.g. ./configure --enable-glx=gallium-xlib --disable-dri --disable-gbm -disable-egl and is used by an X server (usually remotely via SSH X11 forwarding) that does not support MIT-SHM such as XMing or MobaXterm, OpenGL clients report error messages such as Xlib: extension "MIT-SHM" missing on display "localhost:11.0". ad infinitum. The reason is that the code in src/gallium/winsys/sw/xlib uses MIT-SHM without checking for its existence, unlike the code in src/glx/drisw_glx.c and src/mesa/drivers/x11/xm_api.c. I copied the same check using XQueryExtension, and tested with glxgears on MobaXterm. This issue was reported before here: https://lists.freedesktop.org/archives/mesa-users/2016-July/001183.html Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit a203eaa4)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 38f54278)
-
Marek Olšák authored
autotools doesn't have any requirement. This fixes meson on Ubuntu 16.04. Cc: 18.3 19.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> (cherry picked from commit 1e85cfb9)
-
Dylan Baker authored
-
Dylan Baker authored
This reverts commit 8fb8ebfb.
-
Dylan Baker authored
This reverts commit 378f9967. This also remove the default true argument from the a2xx nir backend, which was introduced after this commit. There should be no change in functionality.
-
Dylan Baker authored
This reverts commit af07141b.
-
Dylan Baker authored
-
Faith Ekstrand authored
When nir_rematerialize_derefs_in_use_blocks_impl was first written, I attempted to optimize things a bit by not bothering to re-materialize the sources of deref instructions figuring that the final caller would take care of that. However, in the case of more complex deref chains where the first link or two lives in block A and then another link and the load/store_deref intrinsic live in block B it doesn't work. The code in rematerialize_deref_in_block looks at the tail of the chain, sees that it's already in block B and skips it, not realizing that part of the chain also lives in block A. The easy solution here is to just rematerialize deref sources of deref instructions as well. This may potentially lead to a few more deref instructions being created by the conditions required for that to actually happen are fairly unlikely and, thanks to the caching, it's all linear time regardless. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109603 Fixes: 7d1d1208 "nir: Add a small pass to rematerialize derefs per-block" Reviewed-by:
Alejandro Piñeiro <apinheiro@igalia.com> (cherry picked from commit 9e6a6ef0)
-
- Feb 11, 2019
-
-
Fixes: cd56d79b "nir: check NIR_SKIP to skip passes by name" Reviewed-by:
Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> (cherry picked from commit 78169870)
-
- Feb 07, 2019
-
-
We used to pre-set a bunch of extra arguments to a texture instruction in order to force the RA to allocate a register at the boundary of 4. However with the levelZero optimization, which removes a LOD argument when it's uniformly equal to zero, we undid that logic by removing an extra argument. As a result, we could end up with insufficient alignment on the second wide texture argument. Instead we switch to a different method of achieving the same result. The logic runs during the constraint analysis of the RA, and adds unset sources as necessary right before being merged into a wide argument. Fixes MISALIGNED_REG errors in Hitman when run with bindless textures enabled on a GK208. Fixes: 9145873b ("nvc0/ir: use levelZero flag when the lod is set to 0") Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: 19.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 5de5beed)
-
Kristian Høgsberg authored
We're writing to the bo and the kernel needs to know for fd_bo_cpu_prep() to work. Fixes: f93e4312 ("freedreno/a6xx: Enable blitter") Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Kristian H. Kristensen <hoegsberg@chromium.org> (cherry picked from commit 357ea7da)
-
Can happen e.g. after a phi. Fixes: a2b5cc3c "radv: enable variable pointers" Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 8d171859)
-
Fixes: a2b5cc3c "radv: enable variable pointers" Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 830fd0ef)
-