- Oct 25, 2014
-
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com>
-
- Oct 22, 2014
-
-
Fixes use-after-free when the currently bound blend state is destroyed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85267 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84140 Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Tested-by:
Dieter Nützel <Dieter@nuetzel-hh.de> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit ae879718)
-
We must convert it to boolean from the DX9 float encoding that Gallium specifies. Later, we should probably define that FACE should be 0 or ~0 if native integers are supported. Cc: 10.2 10.3 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 9ec305ea)
-
The get_variable_being_redeclared() function can free the 'var' argument. Thereafter, we cannot assume that 'var' is a valid pointer. This patch replaces 'var->name' with 'earlier->name' in two places and calls is_gl_identifier(var->name) before 'var' might get freed. This fixes several piglit GLSL crashes, including: spec/glsl-1.50/execution/geometry/clip-distance-in-param spec/glsl-1.50/execution/geometry/clip-distance-bulk-copy spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-before-global-redeclaration.geom I'm not sure why these were not spotted sooner. A similar bug was previously fixed by f9cecca7. Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Chris Forbes <chrisf@ijw.co.nz> (cherry picked from commit 14379a06)
-
- Oct 19, 2014
-
-
This fixes a crash when exiting Firefox. I have really no idea how Firefox does it. It seems to involve multiple contexts and multithreading. v2: added an XXX comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81680 Acked by Christian König. Cc: 10.2 10.3 <mesa-stable@lists.freedesktop.org> Tested-by:
Benjamin Bellec <b.bellec@gmail.com> (cherry picked from commit 833d698a)
-
Otherwise the caching buffer manager may return a buffer which was created with a different set of flags, which can cause trouble. Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 3ede67a4) Conflicts: src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
-
Reported by Coverity Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 742158b5)
-
Ideally there would be a swrast fallback, but the driver isn't ready for that. This should avoid crashes if someone tries to use 3d textures though. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 5524af81)
-
The current implementation of glxUseXFont requires creating a temporary pixmap and graphics context, which requires a real old-school X11 Window, not a glxDrawable. This patch changes things so that glxUseXFont will also accept a glxWindow or glxPixmap, and lookup the underlying X11 Drawable. Without this patch glxUseXFont generates a giant stream of Xerrors about bad drawables and bad graphics contexts. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372 Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Brian Paul <brianp@vmware.com> (cherry picked from commit 291be284)
-
- Oct 13, 2014
-
-
When mapping the buffer a second time, we need to use the new pointer, not the one from the previous mapping. Otherwise, we will most likely crash. Apparently, we've just been getting lucky and getting the same bo->virtual pointer in both cases. libdrm probably has a hand in that. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Anuj Phogat <anuj.phogat@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 94841b6d)
-
Write-back caching cannot be used for buffers being scanned out by the display engine; surfaces used for scan-out must be write-through or uncached. I originally chose WT for render targets because it works in all cases. However, we really want to use write-back caching where possible, as it is more efficient. Most renderbuffers are not used for scanout - off-screen FBOs certainly are fine, and non-pageflipped backbuffers should be fine as well. So in most cases WB will work. However, we don't know what will be used for scan-out, so we instead simply use the PTE value specified by the kernel, as it knows these things. This matches our MOCS choice on Haswell. Fixes performance regressions since commit ee4484be in a microbenchmark (spotted by Eero Tamminen). Improves performance in GLBenchmark 2.7/EgyptHD by 7.44362% +/- 0.496939% (n=55) on a Broadwell GT2. Improves performance in a bunch of other microbenchmarks by ~15% or so. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reported-by:
Eero Tamminen <eero.t.tamminen@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Kristian Høgsberg <krh@bitplanet.net> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit b7844d12)
-
Like BDW_MOCS_WB and BDW_MOCS_WT, this specifies that we want to use all three caches (L3, LLC, and eLLC where available), but leaves the LLC caching mode up to the kernel's page table entry. This allows the kernel to pick WB/WT/UC based on whether it's using a buffer for scanout. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Kristian Høgsberg <krh@bitplanet.net> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit d489a8a7)
-
Putting those in VRAM can cause long pauses due to buffers being moved into / out of VRAM. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662 Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7b4276d7)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit c74be01e)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d58037cc)
-
Fixes a release build segfault when wglCreateContextAttribsARB() calls the wglCreateContext() function. Cc: "10.3" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Matthew McClure <mcclurem@vmware.com> (cherry picked from commit 90dc71b4)
-
On Windows, the Piglit primitive-restart test was failing a glGetError()==0 assertion when it was run w/out any command line arguments. Piglit's all.py script only runs primitive-restart with arguments so this case isn't normally hit during a full piglit run. The basic problem is Microsoft's opengl32.dll calls glFlush from wglGetProcAddress() and Piglit uses wglGetProcAddress() to resolve glPrimitiveRestartNV() which is called inside glBegin/End. See comments in the code for more info. Plus, improve the comments for _mesa_alloc_dispatch_table(). Cc: <mesa-stable@lists.freedesktop.org> Acked-by:
Sinclair Yeh <syeh@vmware.com> (cherry picked from commit c7f0755c)
-
Fixes assertion failure while running the Unreal Engine 4 Elemental demo: .../si_blit.c:322:si_decompress_color_textures: Assertion `tex->cmask.size || tex->fmask.size' failed. Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit ed03747e)
-
While running piglit in virgl, I hit an assert in intel driver. "qemu-system-x86_64: intel_tex.c:219: intel_map_texture_image: Assertion `tex_image->TexObject->Target != 0x8C18 || h == 1' failed." Thanks to Eric and Ken for pointing me in the right direction, Fix the get_tex_depth to do the same fixup as get_tex_rgba does for 1D array textures. Reviewed-by:
Brian Paul <brianp@vmware.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 8df3c02c)
-
- Oct 12, 2014
-
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com>
-
- Oct 03, 2014
-
-
With current makefiles the build fails because source and build paths are generated incorrectly. With Android build system the top_srcdir and top_builddir variables are undefined and all paths are relative to where Android.mk is located. This ends up with path likes external/mesa/src/mesa/src/mesa/ for both source and build paths, which are obviously wrong. This patch fixes this by overriding resulting SRCDIR and BUILDDIR variables with empty string, so that paths end up being relative to Android.mk file again. Appending correct build path to generated files is already done in Android.gen.mk. Signed-off-by:
Tomasz Figa <tomasz.figa@gmail.com> CC: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit b4ffd19e)
-
Current Android makefiles lack generation of format_info.c, which is a dependency of main/format.c. This patch adds necessary code to Android.gen.mk. Signed-off-by:
Tomasz Figa <tomasz.figa@gmail.com> CC: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 98445fd2)
-
This patch fixes Android build failures by including src/util directory in compilation. Files inside of this directory are compiled into libmesa_util static library and linked with resulting libGLES_mesa. Signed-off-by:
Tomasz Figa <tomasz.figa@gmail.com> CC: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit d703abf7)
-
Instead of just segfaulting in the driver when a buffer allocation fails, report error messages indicating what went wrong so that we can debug things. As a simple example, chromium wraps Mesa in a sandbox which doesn't allow access to most syscalls, including the ability to create shared memory segments for fences. Before, you'd get a simple segfault in mesa and your 3D acceleration would fail. Now you get: $ chromium --disable-gpu-blacklist [10618:10643:0930/200525:ERROR:nss_util.cc(856)] After loading Root Certs, loaded==false: NSS error code: -8018 libGL: pci id for fd 12: 8086:0a16, driver i965 libGL: OpenDriver: trying /local-miki/src/mesa/mesa/lib/i965_dri.so libGL: Can't open configuration file /home/keithp/.drirc: Operation not permitted. libGL: Can't open configuration file /home/keithp/.drirc: Operation not permitted. libGL error: DRI3 Fence object allocation failure Operation not permitted [10618:10618:0930/200525:ERROR:command_buffer_proxy_impl.cc(153)] Could not send GpuCommandBufferMsg_Initialize. [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(236)] CommandBufferProxy::Initialize failed. [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(256)] Failed to initialize command buffer. This made it pretty easy to diagnose the problem in the referenced bug report. Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681 Signed-off-by:
Keith Packard <keithp@keithp.com> Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Matt Turner <mattst88@gmail.com> (cherry picked from commit 32029267)
-
Commit "st/xa: scissor to help tilers" broke xa_yuv_planar_blit() and vmwgfx textured video. Fix this by implementing scissors also in the yuv draw path. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Cc: Rob Clark <robclark@freedesktop.org> Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 46537f1d)
-
- Sep 28, 2014
-
-
Some users don't understand that these variables can break OpenGL. The general is rule is that if an app supports MSAA, you mustn't use GALLIUM_MSAA. For example, if an app has an 8xMSAA FBO and GALLIUM_MSAA=4 is set, resolving the FBO to the back buffer will be rejected which will look like this on all gallium drivers: http://www.phoronix.com/scan.php?page=article&item=amd_radeonsi_msaa The environment variables also have no effect on modern apps like TF2, but there is still a performance hit due to wasted bandwidth and VRAM. In a nutshell, it does more harm than good. Cc: 10.2 10.3 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit 84491219)
-
- Sep 27, 2014
-
-
This is the only guaranteed way get the patch level for llvm, since the define cannot always be found in config.h depending on the version of llvm or the build system used. CC: 10.2 10.3 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Jonathan Gray <jsg@jsg.id.au> (cherry picked from commit ec566e0f)
-
If the thing being dereferenced is a record or an array of records, it should be treated as row-major. The ir_type_derference_record path already does this, and I think I intended to do the same for this path in b17a4d5d. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83741 Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit c3f17bb1)
-
Per rule #9, the size of the structure is vec4 aligned. The MAX2 in the loop ensures that sizes >= 16 bytes are vec4 aligned. The new MAX2 after the loop ensures that sizes < 16 bytes are vec4 aligned. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82932 Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 2ab71e14)
-
Whether or not the field is row-major (because it might be a bvec2 or something) does not affect the array itself. We need to know whether an array element in its entirety is row-major. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83506 Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 5c75270c)
-
Previously the linker would correctly calculate the layout, but the lower_ubo_reference pass would not apply correct alignment to fields following small (less than 16-byte) nested structures. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83533 Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 8e01c66d)
-
Such buffers can only be useful by reading from them with the CPU, so we need to make sure CPU reads are fast. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84178 Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 7e55c3b3)
-
There is no dedicated instruction for this, so just combine it with the constant offset. Acked-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a5bbfeda)
-
This was missed in the commit that enabled it for fermi/kepler as part of ARB_gpu_shader5 Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit cdc4de12)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0532a5fd)
-
This parallels the fixes in commit afea9bae. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d3c3bba6)
-
What happens is that a SPLIT operation is part of the spill node, and as a pseudo op, the instruction gets erased after processing its first def. However the later defs still need to refer to it, so instead delay deleting until after that whole RA node is done processing. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79462 Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0147c10c)
-