- Jun 19, 2017
-
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.velikov@collabora.com>
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.velikov@collabora.com>
-
- Jun 14, 2017
-
-
Testing with zlib versions 1.2.{3,4,5,6,7,8} showed no difference in functionality, correctness, or zlib API usage and 1.2.3 is the oldest version available in still actively deployed production Linux distributions (RHEL/CentOS 6 and SuSE 11). Build 17.1.1 against the system supplied zlib-devel packages for 1.2.3 in EL6 and 1.2.7 on EL7. I then swapped out the zlib version at runtime via LD_LIBRARY_PATH with ones build from the release tarballs from zlib.net Testwise - I ran the piglit shader profile with --quick addded to the tests since I figured that would exercise the shader cache, which would in turn use zlib. Signed-off-by:
Chuck Atkins <chuck.atkins@kitware.com> Cc: 17.1 <mesa-stable@lists.freedesktop.org> Cc: Timothy Arceri <tarceri@itsqueeze.com> Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> [Emil Velikov: add hunk about version/piglit testing] Acked-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit ad69b037)
-
Fixes for: src/util/rand_xor.c:60:13: error: implicit declaration of function 'open' [-Werror=implicit-function-declaration] int fd = open("/dev/urandom", O_RDONLY); ^~~~ src/util/rand_xor.c:60:34: error: 'O_RDONLY' undeclared (first use in this function) int fd = open("/dev/urandom", O_RDONLY); ^~~~~~~~ Signed-off-by:
Nicolas Dechesne <nicolas.dechesne@linaro.org> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> (cherry picked from commit adadadc1)
-
The max_array_access field applies to the first dimension, which means we only want to set it for the 1D clip dist arrays. This fixes an ir_validate assert seen with KHR-GL44.cull_distance.functional on nouveau and radeon with debug builds. Fixes: a08c4ebb (glsl: rewrite clip/cull distance lowering pass) Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> Tested-by:
Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 53587b71)
-
Fixes trace dumping crash for SI or when RADV_DEBUG=noibs is set. Fixes: 97dfff54 "radv: Dump command buffer on hang." Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit fae3b139)
-
The shader reads the descriptor to decide if it should take the fmask value, however we weren't initing it always, which meant random crap, esp with MSAA depth textures. Fixes random hangs with: dEQP-VK.glsl.builtin_var.fragdepth.* v2: check fmask_state is not NULL Fixes: f4e499ec "radv: add initial non-conformant radv vulkan driver" Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 51553c0b) [Emil Velikov: resolve trivial conflicts] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/amd/vulkan/radv_image.c
-
radeonsi doesn't have it anymore either. Signed-off-by:
Bas Nieuwenhuizen <basni@google.com> Fixes: f4e499ec "radv: add initial non-conformant radv vulkan driver" Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 59c2e2a0)
-
This fixes the subsequent assertion on Bonaire. Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 388d36df)
-
This just sets the vulkan device type depending on whether this is an APU or GPU. Signed-off-by:
Dave Airlie <airlied@redhat.com> Fixes: f4e499ec "radv: add initial non-conformant radv vulkan driver" (cherry picked from commit 2890a711)
-
Sets could have been ignored during previous descriptor set flush due to the shader not using them and therefore no SGPR being assigned. Signed-off-by:
Bas Nieuwenhuizen <basni@google.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Fixes: ae61ddab "radv: move userdata sgpr ownership to compiler side." (cherry picked from commit 4415a46b) Conflicts: src/amd/vulkan/radv_cmd_buffer.c src/amd/vulkan/radv_meta.c
-
We clear the descriptors_dirty array afterwards, so the SGPRs for the other pipeline don't get updated on the flush for that other draw/dispatch, so we have to make sure we do it immediately. Signed-off-by:
Bas Nieuwenhuizen <basni@google.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Fixes: ae61ddab "radv: move userdata sgpr ownership to compiler side." (cherry picked from commit 5fb8bb30) [Emil Velikov: drop radv_flush_indirect_descriptor_sets hunk - missing in branch] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/amd/vulkan/radv_cmd_buffer.c
-
Specification states that in case of error, value should not be written, patch changes buffer age queries to return -1 in case of error so that we can skip changing the value. In addition, small change to droid_query_buffer_age to return 0 in case buffer does not have a back buffer available. Fixes: dEQP-EGL.functional.negative_partial_update.not_postable_surface Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Chad Versace <chadversary@chromium.org> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 8fac894f)
-
Remove c++14 generic lambda to keep compiler requirement at c++11. No regressions on piglit or vtk test suites. Tested-by:
Chuck Atkins <chuck.atkins@kitware.com> Reviewed-by:
Bruce Cherniak <bruce.cherniak@intel.com> CC: mesa-stable@lists.freedesktop.org (cherry picked from commit 0b80b025)
-
The workaround causes a massive performance decrease on 1-SE parts. (Cape Verde, Hainan, Oland) The performance regression is already part of 17.0 and 17.1. v2: check tess_uses_prim_id Cc: 17.0 17.1 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 391673af) [Emil Velikov: s/tcs_tes_uses_prim_id/tess_uses_prim_id/] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com>
-
Cc: "17.0 17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Chad Versace <chadversary@chromium.org> (cherry picked from commit 5097fcbf)
-
Cc: "17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> (cherry picked from commit acbd0245)
-
Cc: "17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> (cherry picked from commit acb9a2ef)
-
Cc: "17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> (cherry picked from commit 252b004a)
-
A number of internal VMware apitrace traces image comparisons fail with dri3 because the viewport transformation becomes incorrect after an X drawable resize. The incorrect viewport transformation sometimes persist until the second draw-call after a swapBuffer. Comparing with the dri2 glx code there are a couple of places where dri2 invalidates the drawable in the absence of server-triggered invalidation, where dri3 doesn't do that. When these invalidation points are added to dri3, the image comparisons become correct. v2: Addressed review comment by Michel Dänzer. Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-and-tested-by:
Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit 1253d589)
-
Only harvested Stoney has 2 CUs. Tested on 2-CU Stoney and Fiji forced to 2 CUs. Cc: 17.0 17.1 <mesa-stable@lists.freedesktop.org> Tested-by:
Edmondo Tommasina <edmondo.tommasina@gmail.com> Tested-by:
Dieter Nützel <Dieter@nuetzel-hh.de> (cherry picked from commit 6c655cfe)
-
This fixes a performance issue with the shader cache that delayed Gallium shader create calls until draw calls. I'd like this in stable, but it's not a showstopper. Cc: 17.1 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> (cherry picked from commit 2ec50f98)
-
BGRA8 image stores on Fermi don't work, which results in breaking PBO downloads, such that they always return 0x0. Discovered this through a glamor bug, and confirmed it does indeed break a good number of piglit tests such as spec/arb_pixel_buffer_object/pbo-read-argb8888 Fixes: 8e7893eb ("nvc0: add support for BGRA8 images") Signed-off-by:
Lyude <lyude@redhat.com> Reviewed-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 245912b6)
-
glXGetCurrentDisplay() has been broken for years and nobody noticed until recently. This change adds a new XMesaGetCurrentDisplay() that the GLX emulation API can call, just as we did for glXGetCurrentContext(). Tested by hacking glxgears to call glXGetCurrentContext() before and after glXMakeCurrent() to verify the return value is NULL beforehand and the same as the opened display afterward. Also tested by Tom Hudson with his tests programs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100988 Cc: mesa-stable@lists.freedesktop.org Tested-by:
Tom Hudson <tom.hudson.phd@gmail.com> Signed-off-by:
Brian Paul <brianp@vmware.com> (cherry picked from commit c6ba85a8)
-
We were linking src/glx with -Bsymbolic, but not the classic/gallium X11 libGL.so. But it's always a good idea to build all libGL.so and all DRI drivers with -Bsymbolic, otherwise they might resolve symbols from the 3rd party application executable or shared libraries, which is _never_ what we want. In particular, this can happen when intercepting OpenGL calls with apitrace, before https://github.com/apitrace/apitrace/commit/63194b2573176ef34efce1a5c8b08e624b8dddf5 Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Brian Paul <brianp@vmware.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit ce5e83b8)
-
This function never occurs in the callchain of a GL function. It occurs only in the callchain of eglCreate*Surface and the analogous paths for GLX. Therefore, even if a thread does have a bound GL context, emitting a GL error here is wrong. A misplaced GL error, when no GL call is made, can confuse clients. Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 9d996e94) [Emil Velikov: resolve trivial conflicts] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/mesa/drivers/dri/i965/intel_fbo.c
-
The cpu_fini() call pushes the buffer back into the GPU domain, which needs to be done for all buffers, not just the ones with CPU written content. The etnaviv kernel driver currently doesn't validate this, but may start to do so at a later point in time. If there is a temporary resource the fini needs to happen before the RS uses this one as the source for the upload. Also remove an invalid comment about flushing CPU caches, cpu_fini takes care of everything involved in this. Fixes: c9e8b49b ("etnaviv: gallium driver for Vivante GPUs") Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By:
Wladimir J. van der Laan <laanwj@gmail.com> (cherry picked from commit cab5996c)
-
- Jun 05, 2017
-
-
Juan A. Suárez authored
Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com>
-
Juan A. Suárez authored
Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com>
-
Juan A. Suárez authored
Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com>
-
- Jun 03, 2017
-
-
Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 39adea93) Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com>
-
Juan A. Suárez authored
This reverts commit b3e48a07.
-
- Jun 02, 2017
-
-
Sandy Bridge does not technically support mipmapped depth/stencil. In order to work around this, we allocate what are effectively completely separate images for each miplevel, ensure that they are page-aligned, and manually offset to them. Prior to layered rendering, this was a simple matter of setting a large enough halign/valign. With the advent of layered rendering, however, things got more complicated. Now, things weren't as simple as just handing a surface off to the hardware. Any miplevel of a normally mipmapped surface can be considered as just an array surface given the right qpitch. However, the hardware gives us no capability to specify qpitch so this won't work. Instead, the chosen solution was to use a new "all slices at each LOD" layout which laid things out as a mipmap of arrays rather than an array of mipmaps. This way you can easily offset to any of the miplevels and each is a valid array. Unfortunately, the "all slices at each lod" concept missed one fundamental thing about SNB HiZ and stencil hardware: It doesn't just always act as if you're always working with a non-mipmapped surface, it acts as if you're always working on a non-mipmapped surface of the same size as LOD0. In other words, even though it may only write the upper-left corner of each array slice, the qpitch for the array is for a surface the size of LOD0 of the depth surface. This mistake causes us to under-allocate HiZ and stencil in some cases and also to accidentally allow different miplevels to overlap. Sadly, piglit test coverage didn't quite catch this until I started making changes to the resolve code that caused additional HiZ resolves in certain tests. This commit switches Sandy Bridge HiZ and stencil over to a new scheme that lays out the non-zero miplevels horizontally below LOD0. This way they can all have the same qpitch without interfering with each other. Technically, the miplevels still overlap, but things are spaced out enough that each page is only in the "written area" of one LOD. Cc: "17.0 17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> (cherry picked from commit 10903d22) Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com>
-
Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 50d0eb50) Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com>
-
This makes us walk over the heaps one at a time and add the types for LLC and !LLC to each heap. Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 34581fdd) Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com>
-
Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit b83b1af6) [Juan A. Suarez: resolve trivial conflicts] Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com> Conflicts: src/intel/vulkan/anv_device.c
-
The idea behind doing this was to make it easier to set various flags. However, we have enough custom flag settings floating around the driver that this is more of a nuisance than a help. This commit has the following functional changes: 1) The workaround_bo created in anv_CreateDevice loses both flags. This shouldn't matter because it's very small and entirely internal to the driver. 2) The bo created in anv_CreateDmaBufImageINTEL loses the EXEC_OBJECT_ASYNC flag. In retrospect, it never should have gotten EXEC_OBJECT_ASYNC in the first place. Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 00df1cd9) [Juan A. Suarez: resolve trivial conflicts] Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com> Conflicts: src/intel/vulkan/anv_allocator.c src/intel/vulkan/anv_device.c src/intel/vulkan/anv_queue.c
-
Instead of returning valid types as just a number, we now walk the list and check the buffer's usage against the usage flags we store in the new anv_memory_type structure. Currently, valid_buffer_usage == ~0. Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit f7736ccf) [Juan A. Suarez: resolve trivial conflicts] Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com> Conflicts: src/intel/vulkan/anv_device.c src/intel/vulkan/anv_private.h
-
Before, we were just comparing the type index to 0. Now we actually look the type up in the table and check its properties to determine what kind of mapping we want to do. Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Cc: "17.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 92325a7e) [Juan A. Suarez: resolve trivial conflicts] Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com> Conflicts: src/intel/vulkan/anv_device.c src/intel/vulkan/anv_private.h
-
Reviewed-by:
Chad Versace <chadversary@chromium.org> (cherry picked from commit 35e626bd) Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com> Squashed with: anv/tests: Create a dummy instance as well as device This fixes crashes caused by 35e626bd which made us start referencing the instance in the allocators. With this commit, the tests now happily pass again. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100877 Tested-by:
Vinson Lee <vlee@freedesktop.org> (cherry picked from commit 6ef1bd4f) Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com>
-