Add a help function for each WA and make PIPE_CONTROL flags match the WA
descriptions. Call gen6_wa_pre_pipe_contro() only before PIPE_CONTROLs.
Fix missing gen6_wa_pre_3dstate_vs_toggle() in the rectlist path.
Replace the _MSC_VER >= 1200 with defined (_MSC_VER) and compact if/else
statements. We require MSVC 2008 or later with commit 46110c5d564.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Implicitly required for a while, although commit 9385c592c6 (mapi:
remove u_thread.h) was the one that put the final nail on the
coffin.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This has been an implicit rule for building mesa for a long time. Let's
make it official and just bail out at configure time. This way we can
cleaning up some of our glx code.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Convert the code to use the C11 threads implementation, and nuke the
Windows non-pthreads code-path. The c11/threads_win32.h abstraction
should be better than the current code.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This is just to help repro and fixing these issues with any C++ compiler --
Commiting this will of course wait until all issues are addressed.
$ scons src/glsl/
scons: Reading SConscript files ...
Checking for GCC ... yes
Checking for Clang ... no
Checking for X11 (x11 xext xdamage xfixes glproto >= 1.4.13)... yes
Checking for XCB (x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 1.8)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm >= 2.4.38)... yes
Checking for UDEV (libudev >= 151)... yes
warning: LLVM disabled: not building llvmpipe
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build/linux-x86_64-debug/glsl
Compiling src/glsl/ast_array_index.cpp ...
Compiling src/glsl/ast_expr.cpp ...
Compiling src/glsl/ast_function.cpp ...
Compiling src/glsl/ast_to_hir.cpp ...
Compiling src/glsl/ast_type.cpp ...
Compiling src/glsl/builtin_functions.cpp ...
In file included from include/c99_compat.h:28:0,
from src/mapi/u_compiler.h:4,
from src/mapi/u_thread.h:47,
from src/mapi/glapi/glapi.h:47,
from src/mesa/main/mtypes.h:42,
from src/mesa/main/errors.h:47,
from src/mesa/main/imports.h:41,
from src/mesa/main/core.h:44,
from src/glsl/builtin_functions.cpp:58:
include/no_extern_c.h:48:1: error: template with C linkage
template<class T> class _IncludeInsideExternCNotPortable;
^
In file included from include/c99_compat.h:28:0,
from include/c11/threads.h:38,
from src/mapi/u_thread.h:49,
from src/mapi/glapi/glapi.h:47,
from src/mesa/main/mtypes.h:42,
from src/mesa/main/errors.h:47,
from src/mesa/main/imports.h:41,
from src/mesa/main/core.h:44,
from src/glsl/builtin_functions.cpp:58:
include/no_extern_c.h:48:1: error: template with C linkage
template<class T> class _IncludeInsideExternCNotPortable;
^
Compiling src/glsl/builtin_types.cpp ...
Compiling src/glsl/builtin_variables.cpp ...
scons: *** [build/linux-x86_64-debug/glsl/builtin_functions.os] Error 1
scons: building terminated because of errors.
Reviewed-by: Mark Janes <mark.a.janes@intel.com>
If scratch space is needed for a shader stage we try to reuse the last scratch
buffer bound to that stage. If we can't, we free the old scratch buffer and
allocate a new one. This means we always keep the last scratch buffer for a
particular shader stage around for the entire life span of the context.
These buffers are being reported by Valgrind as definitely lost after
destroying the OpenGL context. For example, for the geometry shader stage:
==18350== 248 bytes in 1 blocks are definitely lost in loss record 85 of 150
==18350== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18350== by 0xA1B35D6: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:724)
==18350== by 0xA1B383F: drm_intel_gem_bo_alloc (intel_bufmgr_gem.c:794)
==18350== by 0xA1AEFA3: drm_intel_bo_alloc (intel_bufmgr.c:52)
==18350== by 0x9D08E31: brw_get_scratch_bo (brw_program.c:226)
==18350== by 0x9D2A0F2: do_gs_prog (brw_vec4_gs.c:280)
==18350== by 0x9D2A635: brw_gs_precompile (brw_vec4_gs.c:401)
==18350== by 0x9D14F68: brw_shader_precompile(gl_context*, gl_shader_program*) (brw_shader.cpp:76)
==18350== by 0x9D157B8: brw_link_shader (brw_shader.cpp:269)
==18350== by 0x9B0941E: _mesa_glsl_link_shader (ir_to_mesa.cpp:3038)
==18350== by 0x99AE4ED: link_program (shaderapi.c:917)
==18350== by 0x99AF365: _mesa_LinkProgram (shaderapi.c:1385)
So make sure that by the time we destroy the context we check if we have live
scratch buffers for the various stages and release them if that is the case.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Increase the device info .urb.size for CHV to match the default URB
size (192kB).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
This output variables gives more flexibility for future changes
in autoconf to detect if it is needed to auto-generate files and
check for the auto-generation dependencies.
It is still returning error when Python is not installed.
Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Was resulting in gl_PointSize write being optimized out, causing
particle system type shaders to hang if hw binning enabled.
Fixes neverball, OGLES2ParticleSystem, etc.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Use common intrastage array validation for interface blocks.
This change also allows us to support interface blocks
that are arrays of arrays.
V2: Reinsert unsized array asserts in interstage_match()
Reviewed-by: Mark Janes <mark.a.janes@intel.com>
A while back I switched intel_blit_framebuffer to prefer Meta over the
BLT. This meant that Gen8 platforms would start using the 3D engine
for blits, just like we do on Gen6-7.5.
However, I hadn't considered Gen4-5 when making that change. The BLT
engine appears to be substantially faster on 965GM than using Meta to
drive the 3D engine. This isn't too surprising: original Gen4 doesn't
support tile offsets (that came on G45), and the level/layer fields
don't work for cubemap rendering, so for inconvenient miplevel
alignments, we end up blitting or copying data to/from temporaries
in order to render to it. We may as well just use the blitter.
I chose to use the BLT on Gen4-5 because they use the same ring for
both 3D and BLT; Gen6+ splits it out.
Fixes regressions on 965GM due to botched tile offset code (we should
fix those properly as well, but they're longstanding bugs - for now,
put things back to the status quo).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89430
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
The former is used by the kernel driver to set up fence registers and to pass
tiling info across processes. It lacks INTEL_TILING_W, which made our code
less expressive.
System headers may contain C++ declarations, which cannot be given C
linkage. For this reason, include statements should never occur
inside extern "C".
This patch moves the C linkage statements to enclose only the
declarations within a single header.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The SSSE3 swizzling code was written for fast uploads to the GPU and
assumed the destination was always 16-byte aligned. When we began using
this code for fast downloads as well we didn't do anything to account
for the fact that the destination pointer given by glReadPixels() or
glGetTexImage() is not guaranteed to be suitably aligned.
With SSSE3 enabled (at compile-time), some applications would crash when
an SSE aligned-store instruction tried to store to an unaligned
destination (or an assertion that the destination is aligned would
trigger).
To remedy this, tell intel_get_memcpy() whether we're uploading or
downloading so that it can select whether to assume the destination or
source is aligned, respectively.
Cc: 10.5 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89416
Tested-by: Uriy Zhuravlev <stalkerg@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Several patches added include statements where required by the m64
build. Some files are only compiled for m32, and require similar
changes.
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2:
- Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE
and CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
- Only define cl_khr_fp64 if the extension is supported.
- Remove trailing space from extension string.
- Rename device query function from cl_khr_fp64() to
has_doubles().
v3:
- Return 0 for device::doubled_fp_confg() when doubles aren't
supported.
v4:
- Remove device query for double fp_config.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The header is included in ../xmlpool.h. With the latter of which used
directly in a number of places in mesa.
Note that we can also add it (alongside t_option.h) to noinst_HEADERS,
but neither solution fixes the issue that brough us here - namely:
Do not regenerate the headers, if it already exists.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
I.e. add {shared-,}glapi/glapi_mapi_tmp.h to the SOURCES list. Otherwise
there will be no knowledge that the file is required by others for the
build. Thus autotools won't pick it up for the distribution tarball.
v2: Don't forget about the static glapi. Spotted by Matt.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Not required. Additionally this had the side effect of generating the
file, despite it's existence.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Some of the files generated were not in the SOURCES variable, thus
although generated prior to compilation the dependency tracking was
incomplete. The latter of which resulted in the files missing from the
distribution tarball.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The file is auto-generated, and #included by formats.c. Let's rename it
to reflect the latter. This will also help up fix the dependency
tracking by adding it to the _SOURCES variable, without the side effect
of it being compiled (twice).
v2: Update .gitignore to reflect the rename.
Cc: "10.4, 10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Drop the no longer present get_es{1,2}.c from the list.
v2: Keep the format_info.c rename hunk out of this patch.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
All the users directly include the header, plus we have a in-tree
replacements for non C99 compilers which we already use.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Currently these files are including it indirectly via eglcompiler.h
The latter of which will be removed with follow up commits.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Should no longer be used. As many places indirectly include
eglcompiler.h keep this change separate, so that it can be easily
reverted, if needed.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
With the split of the gallium egl module we had previously it required
access to some of the internal functions. As the only build (automake)
that did this no longer builds it we can now appropriately hide those
functions.
Cc: 10.5 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
