- Jan 25, 2017
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
- Jan 24, 2017
-
-
Blits do not need any special treatment as the target buffer object is added to render cache just as one does for normal draw. Color clears and resolves in turn require explicit "end of pipe synchronization". It is not clear what this means exactly but the assumption is that render cache flush with command stream stall should be sufficient. Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 180653c3)
-
instead of calling unconditionally brw_emit_mi_flush() which does: brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_CACHE_FLUSH | PIPE_CONTROL_RENDER_TARGET_FLUSH | PIPE_CONTROL_CS_STALL); brw_emit_pipe_control_flush(brw, PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE | PIPE_CONTROL_CONST_CACHE_INVALIDATE); Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 46b34689)
-
Current blorp logic issues unconditional "flush everything" (see brw_emit_mi_flush()) after each render. For example, all blits issue this unconditionally which shouldn't be needed if they set render cache properly so that subsequent renders do necessary flushing before drawing. In case of piglit: ext_framebuffer_multisample-accuracy all_samples depth_draw small intel_hiz_exec() is always preceded by blorb blit and the unconditional flush looks to hide the lack of stall and flushes in depth clears. By removing the brw_emit_mi_flush() I get gpu hangs. This patch adds the stalls and flushes mandated by the spec and gets rid of those hangs. v2 (Jason, Ken): Document the rational for separating depth cache flush and stall on Gen7. Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit e6da6943)
-
by replacing brw_emit_mi_flush() with brw_render_cache_set_check_flush(). The latter splits the flush in two: brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_CACHE_FLUSH | PIPE_CONTROL_RENDER_TARGET_FLUSH | PIPE_CONTROL_CS_STALL); brw_emit_pipe_control_flush(brw, PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE | PIPE_CONTROL_CONST_CACHE_INVALIDATE); instead of int flags = PIPE_CONTROL_NO_WRITE | PIPE_CONTROL_RENDER_TARGET_FLUSH; if (brw->gen >= 6) { flags |= PIPE_CONTROL_INSTRUCTION_INVALIDATE | PIPE_CONTROL_CONST_CACHE_INVALIDATE | PIPE_CONTROL_DEPTH_CACHE_FLUSH | PIPE_CONTROL_VF_CACHE_INVALIDATE | PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE | PIPE_CONTROL_CS_STALL; } brw_emit_pipe_control_flush(brw, flags); v2 (Jason): Check that destination exists before trying to add to render cache. Depth clears and resolves don't have it. Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 4840a53e)
-
Some CIK-VI docs say this is the default behavior on SI. That doesn't answer whether it's also the default behavior on CIK-VI. Cc: 17.0 13.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 573bf094)
-
Fixes: 97dfff54 ("radv: Dump command buffer on hang.") Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> CC: <mesa-stable@lists.freedesktop.org> (cherry picked from commit f65b3641)
-
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 00847e4f)
-
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 b829206b)
-
Fixes GL45-CTS.gpu_shader_fp64.built_in_functions. v2: use DDIV unconditionally (Roland) Reviewed-by: Roland Scheidegger <sroland@vmware.com> (v1) Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1) 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 cfabbbcf)
-
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 b71c415c)
-
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 e4f8f9a6)
-
We will use it for DDIV. 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 488560cf)
-
It seems clear that trying to multiply two pairs of doubles would result in the temporary register getting overwritten by the second pair. So make the code more explicit. 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 76b02d2f)
-
Signed-off-by: Rob Clark <robdclark@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 31daeb5b)
-
What a3xx docs call IJPERSPCENTERREGID.. the xy coord passed into bary.f. We were incorrectly setting both this and gl_FragCoord.xy to the same register resulting in all sorts of hilarity. Fixes stk, vdrift, 0ad, probably a bunch others. Signed-off-by: Rob Clark <robdclark@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 8d6af93e)
-
Note spritelist (POINTLIST_PSIZE) seems not to be a thing anymore on a5xx. Signed-off-by: Rob Clark <robdclark@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 6cc93bed)
-
Signed-off-by: Rob Clark <robdclark@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 141a4f86)
-
Signed-off-by: Rob Clark <robdclark@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 69fbb458)
-
Signed-off-by: Rob Clark <robdclark@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 16671e97)
-
Signed-off-by: Rob Clark <robdclark@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 4d9aa4f6)
-
Signed-off-by: Rob Clark <robdclark@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 4c394584)
-
The previous code always compared integers as 64-bit. Due to variations in sign-extension in the code generated by nir_opt_algebraic.py, this meant that nir_search doesn't always do what you want. Instead, 32-bit values should be matched as 32-bit and 64-bit values should be matched as 64-bit. While we're here we unify the unsigned and signed paths. Now that we're using the right bit size, they should be the same since the only difference we had before was sign extension. This gets the UE4 bitfield_extract optimization working again. It had stopped working due to the constant 0xff00ff00 getting sign-extended when it shouldn't have. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Eric Anholt <eric@anholt.net> Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit bb96b034)
-
In order to handle CCS_E, we stomp the image format to a UINT format and then do some bitcasting logic in the shader. This works fine since SKL render compression only considers the channel layout of the format and not the format itself. In order for this to work on images that have been fast-cleared, we need to also convert the clear color so that, when interpreted as UINT, it provides the same bit value as it would have in the original format. This fixes a bunch of OpenGL ES CTS tests for copy_image when we start using CCS more aggressively. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 817f9e3b)
-
- Jan 20, 2017
-
-
In situations where libdrm_amdgpu and mesa are installed to the same location, the mesa installed headers will take precedence over the git source headers. This is due to the AMDGPU_CFLAGS containing the install directory. This situation can cause build errors if the git version of a header is newer than the currently installed version of a header (e.g. git pull updates vulkan.h) Note: using the same install prefix for mesa and libdrm is probably a common occurrence since it is described in the radeonBuildHowTo wiki: https://www.x.org/wiki/radeonBuildHowTo/ v2: added sign-off Signed-off-by: Andres Rodriguez <andresx7@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit a3ad6a34)
-
The current message sounds like a small warning, clarify that it can result in lack of presentation support and application crashes. v2: add "if they do" (Bas) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98263 Signed-off-by: Andres Rodriguez <andresx7@gmail.com> Acked-by: Jason ekstrand <jason@jlekstrand.net> Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit e0674e74)
-
Blorp can deal with depth/stencil surfaces blits/copies without the render target requirement. Also having both render target and depth/stencil requirement is incompatible from isl's point of view. This fixes an image creation issue in the high level quality settings of the Unity3D player, which requires a depth texture with src/dst transfer & 4x multisampling. v2: Simply aspect checking condition (Jason) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: 13.0 17.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 74c23bde)
-
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 8a28e764)
-
Fixes: e99b9395 "gallium/hud: Add support for CPU frequency monitoring" Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 383fc8e9)
-
This fixes VM faults. Discovered by Samuel Pitoiset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98975 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99450 Cc: 17.0 13.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> (cherry picked from commit e490b781)
-
At least on VI, texture gather doesn't work with a 24_8 data format, so use 8_8_8_8 and a modified swizzle instead. A bit of background: When creating a GL_STENCIL_INDEX8 texture, we select the X24S8 pipe format because we don't support stencil-only render targets properly. With mip-mapping this can lead to a setup where the tiling is incompatible with stencil texturing, and a flushed stencil texture is used. For the flushed stencil, a literal X24S8 is used because there were issues with an 8bpp DB->CB copy. Longer term, it would be good if we could get away from these workarounds, i.e. properly support an S8 format for stencil-only rendering and flushed stencil. Since stencil texturing is somewhat rare, it's not a high priority. Fixes GL45-CTS.texture_cube_map_array.sampling. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net> (cherry picked from commit 3cd092c4)
-
This commit makes si_update_poly_offset set poly_offset to NULL if uses_poly_offset is false. This way poly_offset either points into the currently queued rasterizer, or it is NULL. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99451 Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit d7d32b3b)
-
Since _mesa_ClampColor properly checks for support of the API function now, it's meta callers need to check support as well. Fixes: 963311b7 ("mesa/main: fix version/extension checks in _mesa_ClampColor") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99401 Tested-by: Mark Janes <mark.a.janes@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a7c635ec)
-
This fixes the build on ppc/s390. Reviewed-by: Roland Scheidegger <sroland@vmware.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit ef71b867)
-
- Jan 18, 2017
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Emil Velikov authored
Fixes: d1efa09d "util: import sha1 implementation from OpenBSD" Signed-off-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit ea8b2624)
-
Emil Velikov authored
Earlier commit imported a SHA1 implementation and relaxed the SHA1 and disk cache handling, broking the Windows builds. Restrict things for now until we get to a proper fix. Fixes: d1efa09d "util: import sha1 implementation from OpenBSD" Signed-off-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 9f8dc3bf)
-
Emil Velikov authored
At the moment we support 5+ different implementations each with varying amount of bugs - from thread safely problems [1], to outright broken implementation(s) [2] In order to accommodate these we have 150+ lines of configure script and extra two configure toggles. Whist an actual implementation being ~200loc and our current compat wrapping ~250. Let's not forget that different people use different code paths, thus effectively makes it harder to test and debug since the default implementation is automatically detected. To minimise all these lovely experiences, import the "100% Public Domain" OpenBSD sha1 implementation. Clearly document any changes needed to get building correctly, since many/most of those can be upstreamed making future syncs easier. As an added bonus this will avoid all the 'fun' experiences trying to integrate it with the Android and SCons builds. v2: Manually expand __BEGIN_DECLS/__END_DECLS and document (Tapani). Furthermore it seems that some games (or surrounding runtime) static link against OpenSSL resulting in conflicts. For more information see the discussion thread [3] Bugzilla [1]: https://bugs.freedesktop.org/show_bug.cgi?id=94904 Bugzilla [2]: https://bugs.freedesktop.org/show_bug.cgi?id=97967 [3] https://lists.freedesktop.org/archives/mesa-dev/2017-January/140748.html Cc: Mark Janes <mark.a.janes@intel.com> Cc: Vinson Lee <vlee@freedesktop.org> Cc: Tapani Pälli <tapani.palli@intel.com> Cc: Jonathan Gray <jsg@jsg.id.au> Tested-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Acked-by: Tapani Pälli <tapani.palli@intel.com> (v1) Acked-by: Jason Ekstrand <jason@jlekstrand.net> (v1)
-
Kenneth Graunke authored
struct brw_cache_item is an implementation detail of the program cache. We don't need to make those internals available to the entire driver. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
-
Marek Olšák authored
v2: now it should be correct Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
-