- Dec 05, 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>
-
Such as: Warning: LLVM emitted unknown config register: 0x4 This is a non-intrusive back port of commit 0f7a6ea5.
-
This fixes dual source blending on Stoney. The fix was copied from Vulkan. The problem was discovered during internal testing. Cc: 13.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 5e5573b1)
-
copied from Vulkan Cc: 13.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit ff50c44a)
-
better safe than sorry Cc: 13.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 87b208a5) Conflicts: src/gallium/drivers/radeonsi/si_state.c
-
- Dec 02, 2016
-
-
Framebuffer attachments can be specified through FramebufferTexture* calls. Upon specifying a depth (or stencil) framebuffer attachment that internally reuses a texture, the cube map face of the new attachment would not be updated (defaulting to TEXTURE_CUBE_MAP_POSITIVE_X). Fix this issue by actually updating the CubeMapFace field. This bug manifested itself in BindFramebuffer calls performed on framebuffers whose stencil attachments internally reused a depth texture. When binding a framebuffer, we walk through the framebuffer's attachments and update each one's corresponding gl_renderbuffer. Since the framebuffer's depth and stencil attachments may share a gl_renderbuffer and the walk visits the stencil attachment after the depth attachment, the uninitialized CubeMapFace forced rendering to TEXTURE_CUBE_MAP_POSITIVE_X. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77662 Signed-off-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 63318d34)
-
v2: use a function for calculating WORD1 of bo metadata [Lyude] On Fedora 24 and 25, I ended up noticing some rather nasty graphical glitches on my desktop (using an R9 380 w/ amdgpu, Mesa version 12.0.4) while I was in Wayland where the content of windows was garbled, as seen here: https://people.freedesktop.org/~lyudess/archive/11-30-2017/amdgpu-fix-example.png After doing some reverse bisecting with Mesa v13, I ended up tracking down the fix to this patch, which seems to fix the problem entirely on all of the systems I've tested. Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Tested-by: Lyude <lyude@redhat.com> CC: "12.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 095803a3)
-
git history shows "abi_versions" was used from the outset. Cc: <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98415 Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 07755237)
-
Reviewed-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit b425b57d)
-
Sometimes it was f32, other times it was i32. Now it's always i32. This fixes: GL45-CTS.texture_cube_map_array.image_texture_size.texture_size_compute_sh Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 3e756f09)
-
This fixes: GL45-CTS.tessellation_shader.tessellation_control_to_tessellation_evaluation .gl_PatchVerticesIn Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 03708dee)
-
Calculate depth ranges from viewport states and pipe_rasterizer_state::clip_halfz. The evergreend.h change is required to silence a warning. This fixes this recently updated piglit: arb_depth_clamp/depth-clamp-range Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 687c4be9)
-
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 8b050767)
-
The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_REV are not defined anywhere in OpenGL ES 3.2 (or earlier) specification, and there are no known extensions in the Khronos registry that would add these enums as valid responses for glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_TYPE) and glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_FORMAT) queries. Note that this patch does not change the bit layout returned by the query. As defined by the GL spec, the bit layout of GL_RGB + GL_UNSIGNED_SHORT_5_6_5 and GL_BGR + GL_UNSIGNED_SHORT_5_6_5_REV are identical. TEST=dEQP-GLES3.functional.state_query.integers.* Signed-off-by: Haixia Shi <hshi@chromium.org> Reviewed-by: Chad Versace <chadversary@chromium.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: Stéphane Marchesin <marcheu@chromium.org> Change-Id: I81bbc8ccdc7e125edaeae443baf6fa8fdefcc6b6 (cherry picked from commit 8c56ff64)
-
As this array was not actually sorted, FindGLXFunction's binary search would only sometimes work. Cc: "13.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 8bca8d89)
-
Cc: "13.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit deb0eb16)
-
There is currently no protection against walking a hash (using _mesa_HashWalk()) and modifying it at the same time, for instance by inserting or deleting elements. This leads to segfaults in multithreaded code if e.g. someone calls glTexImage2D (which may have to walk the list of FBOs) while another thread is calling glDeleteFramebuffers on another thread with the two contexts sharing lists. The reason for this is that _mesa_HashWalk() doesn't actually take the mutex that normally protects the hash; it takes an entirely different mutex. Thus, walks are only protected against other walks, and there is also no outer lock taking this. There is an old comment saying that this is to fix problems with deadlock if the callback needs to take a mutex; we solve this by changing the mutex to be recursive. A demonstration Helgrind hit from a real application: ==13412== Possible data race during write of size 8 at 0x3498C6A8 by thread #1 ==13412== Locks held: 2, at addresses 0x1AF09530 0x2B3DF400 ==13412== at 0x1F040C99: _mesa_hash_table_remove (hash_table.c:395) ==13412== by 0x1EE98174: _mesa_HashRemove_unlocked (hash.c:350) ==13412== by 0x1EE98174: _mesa_HashRemove (hash.c:365) ==13412== by 0x1EE2372D: _mesa_DeleteFramebuffers (fbobject.c:2669) ==13412== by 0x6105AA4: movit::ResourcePool::cleanup_unlinked_fbos(void*) (resource_pool.cpp:473) ==13412== by 0x610615B: movit::ResourcePool::release_fbo(unsigned int) (resource_pool.cpp:442) [...] ==13412== This conflicts with a previous read of size 8 by thread #20 ==13412== Locks held: 2, at addresses 0x1AF09558 0x1AF73318 ==13412== at 0x1F040CD9: _mesa_hash_table_next_entry (hash_table.c:415) ==13412== by 0x1EE982A8: _mesa_HashWalk (hash.c:426) ==13412== by 0x1EED6DFD: _mesa_update_fbo_texture.part.33 (teximage.c:2683) ==13412== by 0x1EED9410: _mesa_update_fbo_texture (teximage.c:3043) ==13412== by 0x1EED9410: teximage (teximage.c:3073) ==13412== by 0x1EEDA28F: _mesa_TexImage2D (teximage.c:3105) ==13412== by 0x166A68: operator() (mixer.cpp:454) There are many more interactions than just these two possible. Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org> Signed-off-by: Steinar H. Gunderson <steinar+mesa@gunderson.no> Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com> (cherry picked from commit 2e2562ca)
-
This fixes hangs in Dota2 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a6c3d0f9)
-
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 1e3e347f)
-
Emil Velikov authored
The patch was reverted shortly after it was merged. Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
This patch should have been the part of commit e592f7df. In a situation when there are multiple render targets with alpha testing enabled, if fragment shader doesn't write to draw buffer zero, it causes the GPU hang on SKL. No GPU hang is seen on HSW. Simulator gives a warning for all gen6+ h/w: "Illegal render target write message length 0xa expected 0xc" This patch fixes the GPU hang as well as the simulator warning with new piglit test fbo-mrt-alphatest-no-buffer-zero-write: https://patchwork.freedesktop.org/patch/118212 No regressions in Jenkins CI system. Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (cherry picked from commit b9df2251)
-
This fixes a crash in Deus Ex: Mankind Divided. Release builds were unaffected, so it's not too serious. Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 00baaa47)
-
The address immediate field is only 9 bits and, since the value is in bytes, the highest GRF we can point to with it is g15. This makes it pretty close to useless for MOV_INDIRECT. There were already piles of restrictions preventing us from using it prior to Broadwell, so let's get rid of the gen8+ code path entirely. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97779 Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 2a4a8686)
-
v2: use signed compare, remove unneeded vmask Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com> (cherry picked from commit f8109076)
-
d3d97f83 broke llvm-3.7, which has a mismatched API for setDataLayout/getDataLayout. Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com> (cherry picked from commit ae4f2c84)
-
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com> (cherry picked from commit d3d97f83)
-
- Nov 30, 2016
-
-
Kenneth Graunke authored
We had missed a bit of errata - PS scratch needs to be computed as if there were 4 subslices per slice, rather than 3. This is a conservative backport of commit aaee3daa. It only increases the scratch amount, unlike the original commit which decreases it on Skylake GT1-3 to avoid overallocating. Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
-
- Nov 23, 2016
-
-
Marek Olšák authored
This should fix random GPU hangs on Hawaii and Fiji. It's already been fixed in 13.0 and later. Cc: 11.2 12.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
-
- Nov 11, 2016
-
-
Marek Olšák authored
This is for 12.0 and older. A different commit fixes 13.0 and newer. Cc: 11.2 12.0 <mesa-stable@lists.freedesktop.org>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
- Nov 10, 2016
-
-
Add mesa_glinterop.h to the list of headers that will get included in the distfile as it is required to build Mesa itself. Corrects a regression introduced in a89faa20. Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 23392abf)
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
- Nov 08, 2016
-
-
This reverts commit d180de35. This is a radeon specific hack that causes problems on nouveau when combined with the SHARED flag later. If radeonsi needs a fix for this, please fix it in the driver. [chk] Using linear surfaces for this makes sense because tilling isn't beneficial and the surfaces can potentially be shared with other GPUs using the VDPAU OpenGL interop. [airlied] I think we need a flag that isn't SHARED/LINEAR that is more SHARED_OTHER_GPU. [mareko] Does radeonsi need PIPE_BIND_VIDEO_DECODE_OUTPUT that it would translate into linear ? [mareko] My only concern is decoding performance. If the decoder works in 64x1 blocks, tiling will hurt. That's the theory. I don't know how the decoder works. Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Tested-by: Ilia Mirkin <imirkin@alum.mit.edu> Tested-by: Nayan Deshmukh <nayan26deshmukh@gmail.com> (I+A) (cherry picked from commit d0d5f760)
-
This was broken when the GLAPI use was removed from mesa_glinterop.h. Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 64c2593a)
-
This was broken when the GLAPI use was removed from mesa_glinterop.h. Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit ee39d445)
-
I need the definition of PUBLIC. Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit bf51b453) [Emil Velikov: Keep the MIN2 macro] Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Previously, we were creating the shader with a NULL ralloc context and then trusting in blorp_compile_fs to clean it up. The only problem was that blorp_compile_fs didn't clean up its context properly so we were leaking. When I went to fix that, I realized that it couldn't because it has to return the shader binary which is allocated off of that context and used by the caller. The solution is to make blorp_compile_fs take a ralloc context, allocate the nir_shaders directly off that context, and clean it all up in whatever function creates the shader and calls blorp_compile_fs. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com> Cc: "12.0, 13.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 43dadb6e) [Emil Velikov: attribute src/intel/blorp file movement] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Conflicts: src/intel/blorp/blorp.c src/intel/blorp/blorp_clear.c src/intel/blorp/blorp_priv.h src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
-
The emitter tried to emit sub instead of subr when src0 has actually a NEG modifier. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0 12.0 13.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 84e94638)
-