- Jul 08, 2016
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
SVGA_3D_CMD_DX_GENRATE_MIPMAP & SVGA_3D_CMD_DX_SET_PREDICATION commands are not presents in fedora 24 kernel module. Because of this reason application like supertuxkart are not running. v2: Add few comments and code modifications suggested by Brian P. Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Charmaine Lee <charmainel@vmware.com> (cherry picked from commit 7988513a)
-
If a shader has an output array, it will get treated as though it were gl_FragData and rewritten into gl_out_FragData instances. We only want this to happen on the actual gl_FragData and not everything else. This is a small part of the problem pointed out by the below bug. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96765 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a37e4632)
-
- Jul 07, 2016
-
-
Emil Velikov authored
After a recent Bugzilla update the word is no longer in the title. Thus the script ended up producing bogus HTML. Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit f35f8464)
-
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Akihiko Odaki <akihiko.odaki.4i@stu.hosei.ac.jp> [Emil Velikov: Drop guards around dri_interface.h, add stable tag] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 42968424)
-
Since the function is exported like any other public api function and put in the header as if you could link against it, export it also from shared objects. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 13affe0d)
-
Some games are sloppy.. perhaps because it is defined behavior for DX or perhaps because nv blob driver defaults things to zero. So add driconf param to force uninitialized variables to default to zero. This issue was observed with rust, from steam store. But has surfaced elsewhere in the past. Signed-off-by: Rob Clark <robclark@freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit f78a6b1c)
-
Signed-off-by: Rob Clark <robclark@freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 01ccb0d9)
-
Devices with smaller GMEM size need more tiles. On db410c at 2048x1152, glmark2 shadow needed ~330 tiles for fullscreen. Lets bump it up to 512. (Maybe with MRT you could end up needing more, but at that point things are probably going to be painfully slow.) Signed-off-by: Rob Clark <robdclark@gmail.com> (cherry picked from commit 7295428e)
-
Emil Velikov authored
Atm the actual rule will expand to foo.o which is used for static libraries only. Thus the automake manual recommendation [to use OBJEXT] won't help us, since since we're working with a shared library. Thus let's 'demote' the file and add it back to BUILT_SOURCES. This will manage all the complexity for us, at the (existing expense) of working only with the all, check and install targets. The crazy (why the issue was hard to spot): If the dependencies (.deps/*.Plo) are already created one can alter the anv_device.$(OBJEXT) line and/or nuke it all together. That won't lead to any warnings/issues, even though the Makefile is regenerated. Moral of the story: Always rm -rf top_builddir or don't resolve the dependencies manually and use BUILT_SOURCES. Cc: "12.0" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96825 Fixes: d7a604c3f7a ("anv: use cache uuid based on the build timestamp.") Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Mark Janes <mark.a.janes@intel.com> (cherry picked from commit 9618e2a2)
-
Emil Velikov authored
As mentioned by the spec (and used by Archlinux and Debian) default to ${datarootdir} as opposed to ${sysconfdir} for the default location. Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit cbc37f72)
-
Emil Velikov authored
Otherwise things will fail to build, if the builder is using another version of LLVM. v2: annotate all the dependencies of builder_gen.h v3: clean the generated files as needed v4: comment cleanups (Tim) Cc: "12.0" <mesa-stable@lists.freedesktop.org> Tested-by: Tim Rowley <timothy.o.rowley@intel.com> Tested-by: Chuck Atkins <chuck.atkins@kitware.com> (v2) Reported-by: Chuck Atkins <chuck.atkins@kitware.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 744d0d8f)
-
Emil Velikov authored
It has proven subtle to get it right both from the build side POV (see commit list below) and builders due to their varying workflows. Furthermore it does not fully fulfil the reason why it was enforced - to detect uniqueness between different builds, in order to distinguish and invalidate Vulkan/GL caches. With that having a much better solution (previous commit) we can drop this solution. This effectively reverts the following commits: 359d9dfe ("mesa: automake: add directory prefix for git_sha1.h") 2c424e00 ("mesa: automake: ensure that git_sha1.h.tmp has the right attributes") b7f7ec78 ("mesa: automake: distclean git_sha1.h when building OOT") 8229fe68 ("automake: get in-tree `make distclean' working again.") Cc: Timo Aaltonen <tjaalton@debian.org> Cc: Haixia Shi <hshi@chromium.org> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (cherry picked from commit 22e93570)
-
Emil Velikov authored
Do not rely on the git sha1: - its current truncated form makes it less unique - it does not attribute for local (Vulkand or otherwise) changes Use a timestamp produced at the time of build. It's perfectly unique, unless someone explicitly thinkers with their system clock. Even then chances of producing the exact same one are very small, if not zero. v2: Remove .tmp rule. Its not needed since we want for the header to be regenerated on each time we call make (Eric). v3: - Honour SOURCE_DATE_EPOCH, to make the build reproducible (Michel) - Replace the generated header with a define, to prevent needless builds on consecutive `make' and/or `make install' calls. (Dave) v4: - Keep the timestamp generation at make time. (Jason) v5: - Ensure that file is regenerated on incremental builds. Cc: Michel Dänzer <michel@daenzer.net> Cc: Dave Airlie <airlied@gmail.com> Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit addb099c)
-
Emil Velikov authored
Considering how hard/annoying it was for many peoples' workflow to properly generate the macro, it will be demoted to conditionally available with follow-up commits. v2: Kill off gracious blank line (Vedran). Cc: mesa-stable@lists.freedesktop.org Cc: Vedran Miletić <vedran@miletic.net> Cc: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1) Reviewed-by: Vedran Miletić <vedran@miletic.net> (cherry picked from commit f98530b7)
-
This reverts commit 27d456cc. DOH, what seems right and what is right with fp64 are always two different things. This regressed: spec@arb_gpu_shader_fp64@shader_storage@layout-std140-fp64-mixed-shader on radeonsi Reported-by: Michel Dänzer <michel@daenzer.net> Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit cb728df9)
-
In presence of an indirect image access, the base offset should be zeroed because the stride will be computed twice. This is a pretty rare situation but it can happen when tex.r > 0. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit f3b9fff3)
-
When emitting OP_SUB, the sign bit for FADD and FADD32I is not at the same position. It's at position 45 for FADD but 51 for FADD32I. This fixes the following piglit test: tests/spec/arb_fragment_program/fdo30337b.shader_test Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit cb828b7b)
-
The image usage specified by the caller of vkCreateSwapchainKHR should be passed onto the internal image creation. Otherwise the driver might later crash when the user tries to use the image as a combined sampler even though the creation was explicitly created with VK_IMAGE_USAGE_TRANSFER_SRC_BIT. Leaving the previous VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT as this might be expected even if the swapchain is created without any flag. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96791 Cc: "12.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit dbbc4fb4)
-
Immediates are stored into a separate table, and are consolidated, so if we get an immediate we don't need to offset it as the index it has is correct. Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 27d456cc)
-
Otherwise, 1x1 images of arbitrarily high level are accepted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96639#add_comment Cc: 11.2 12.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 07cc838b)
-
Fixes a regression introduced by commit 42624ea8 which triggered an assertion in dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0 While stImage must have a non-zero size as verified by the caller, we also look at the size of the base image in an attempt to make a better guess at the level0 size (this is important when the base image size is odd). However, the base image may have a zero size even when it exists. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96629 Cc: 12.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 0ba053b3)
-
This aligns the 4-element color float array to 16 byte boundaries. This should allow compiler vectorizers to generate better optimizations. Also fixes broken vectorization generated by Intel compiler. v2: Fixed indentation and added a lengthy comment explaining the reason for the alignment. Cc: <mesa-stable@lists.freedesktop.org> Reported-by: Tim Rowley <timothy.o.rowley@intel.com> Tested-by: Tim Rowley <timothy.o.rowley@intel.com> Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com> Acked-by: Roland Scheidegger <sroland@vmware.com> (cherry picked from commit d8d6091a)
-
Emil Velikov authored
This reverts commit a380199e3968462da8291e8dda25888f19e86783.
-
Encapsulate the test for which flags are needed to get a compiler to support certain features. Along with this, give various options to try for AVX and AVX2 support. Ideally we want to use specific instruction set feature flags, like -mavx2 for instance instead of -march=haswell, but the flags required for certain compilers are different. This allows, for AVX2 for instance, GCC to use -mavx2 -mfma -mbmi2 -mf16c while the Intel compiler which doesn't support those flags can fall back to using -march=core-avx2. This addresses a bug where the Intel compiler will silently ignore the AVX2 instruction feature flags and then potentially fail to build. v2: Pass preprocessor-check argument as true-state instead of false-state for clarity. v3: Reduce AVX2 define test to just __AVX2__. Additional defines suchas __FMA__, __BMI2__, and __F16C__ appear to be inconsistently defined w.r.t thier availability. v4: Fix C++11 flags being added globally and add more logic to swr_require_cxx_feature_flags Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com> Tested-by: Tim Rowley <timothy.o.rowley@Intel.com> Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com> (cherry picked from commit c1bf6692) Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Khronos recommends that the GLES 3.1 library also be called libGLESv2. It also requires that functions be statically linkable from that library. NOTE: Mesa has supported the EGL_KHR_get_all_proc_addresses extension since at least Mesa 10.5, so applications targeting Linux should use eglGetProcAddress to avoid problems running binaries on systems with older, non-GLES 3.1 libGLESv2 libraries. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> Cc: Mike Gorchak <mike.gorchak.qnx@gmail.com> Reported-by: Mike Gorchak <mike.gorchak.qnx@gmail.com> Acked-by: Chad Versace <chad.versace@intel.com> (cherry picked from commit 5921f372)
-
Fixes a h265 video corruption bug which caused by uvd fw interface changes. Signed-off-by: sonjiang <sonny.jiang@amd.com> Cc: "12.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> (cherry picked from commit b928ff6f)
-
Adapt driver for Polairs uvd firmware interface changes. Signed-off-by: sonjiang <sonny.jiang@amd.com> Cc: "12.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> (cherry picked from commit 5c80354a)
-
Because Polaris uvd fw interface changes, the driver need to check fw version to apply right interface. This change is to add uvd fw version. Signed-off-by: sonjiang <sonny.jiang@amd.com> Cc: "12.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> (cherry picked from commit 28f85eab) [Emil Velikov: resolve trivial s/bool/boolean/ conflicts] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Conflicts: src/gallium/drivers/radeon/radeon_winsys.h
-
Rely on the existence of a second destination when emitting a setcond flag is dangerous, because this doesn't mean that the flag has been correctly set. Instead rely on flagsDef like what emitX() does for flagsSrc. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit cc97b6a3)
-
This was missing. Cc: 12.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c1dbc563)
-
emit_urb_writes() contains code to emit an EOT write with no actual data when there are no output varyings. This makes sense for the VS and TES stages, where it's called once at the end of the program. However, in the geometry shader stage, emit_urb_writes() is called once for every EmitVertex(). We explicitly emit a URB write with EOT set at the end of the shader, separately from this path. So we'd better not terminate the thread. This could get us into trouble for shaders which do EmitVertex() with no varyings followed by SSBO/image/atomic writes. It also caused us to emit multiple sends with EOT set, which apparently confuses the register allocator into not using g112-g127 for all but the first one. This caused EU validation failures in OglGSCloth shaders in shader-db. (The actual application was fine, but shader-db thinks there are no outputs because it doesn't understand transform feedback.) Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> (cherry picked from commit 7e7e501a)
-
The only part of an ir_texture which can be an array is the offsets array in textureGatherOffsets() calls. We don't want to lower those, because they're required to remain constants. Fixes textureGatherOffsets with Gallium drivers such as llvmpipe, which commit ef78df8d regressed. Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit a36a73a7)
-
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7b9b0967)
-
LOP only allows to emit 19-bits immediates. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit 83a4f28d)
-
These need to be passed from the host in caps structure if they are larger, this fixes a bunch of tests on Intel hw, that I'd put the limits too high for. Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit c7cc264c)
-
MOV only allows to emit 19-bits immediates. This is similar to the previous fix I did for IMUL. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit c7fa3c92)
-
This wasn't handled correctly for multi-plane images on gen < 7 in 727a9b24. Reported-by: Mark Janes <mark.a.janes@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96674 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: "12.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 367cf3a2)
-
IMUL only allows to emit 19-bits immediates. This is similar to d3076802 which fixed the same thing for the GK110 emitter. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <mesa-stable@lists.freedesktop.org> (cherry picked from commit b84c9758)
-