Fixes:
GL44-CTS.texture_barrier_ARB.same-texel-rw-multipass
On Haswell, Broadwell and Skylake (note that in order to execute that
test, it is needed to override GL and GLSL versions).
On gen6 this test was already working without this change. It keeps
working after it.
This commit replaces the call to brw_emit_mi_flush for gen6+ with two
calls to brw_emit_pipe_control_flush:
* The first one with RENDER_TARGET_FLUSH and CS_STALL set to initiate
a render cache flush after any concurrent rendering completes and
cause the CS to stop parsing commands until the render cache
becomes coherent with memory.
* The second one have TEXTURE_CACHE_INVALIDATE set (and no CS stall)
to clean up any stale data from the sampler caches before rendering
continues.
Didn't touch gen4-5, basically because I don't have a way to test
them.
More info on commits:
0aa4f99f5672473658c5
Thanks to Curro to help to tracking this down, as the root case was a
hw race condition.
v2: use two calls to pipe_control_flush instead of a combination of
gen7_emit_cs_stall_flush and brw_emit_mi_flush calls (Curro)
v3: no need to const cache invalidation (Curro)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The output of draw requires a null viewport transform, which the regular
code is ill-equiped to do. Reinstate the original settings in the render
path, and add setting of the viewport clip polygon based on fb
width/height (as that is all taken care of by draw).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
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>
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>
The linker deals with atomic counters in terms of uniforms but the
data structure are called after the atomic counters.
Renamed the data structures used in the linker for disambiguation.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Currently the linker uses the uniform count for the total number of
atomic counters. However uniforms don't include the innermost array
dimension in their count, but atomic counters are expected to include
them.
Although the spec doesn't directly state this, it's clear how offsets
will be assigned for arrays.
From OpenGL 4.2 (Core Profile), page 98:
" * Arrays of type atomic_uint are stored in memory by element
order, with array element member zero at the lowest offset. The
difference in offsets between each pair of elements in the
array in basic machine units is referred to as the array
stride, and is constant across the entire array. The stride can
be queried by calling GetIntegerv with a pname of
ATOMIC_COUNTER_- ARRAY_STRIDE after a program is linked."
From that it is clear how arrays of atomic counters will interact with
GL_MAX_ATOMIC_COUNTER_BUFFER_SIZE.
For other kinds of uniforms it's also clear that each entry in an
array counts against the relevant limits.
Hence, although inferred, this is the expected behavior.
Fixes GL44-CTS.arrays_of_arrays_gl.AtomicDeclaration
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
So that we do copies host-side rather than in the guest with map/memcpy.
Tested with piglit arb_copy_buffer-subdata-sync test and new
arb_copy_buffer-intra-buffer-copy test.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
With host-side buffer copies (via SVGA3D_vgpu10_BufferCopy()) we have
to make sure any pending map-write operations are completed before reading
if the buffer is dirty. Otherwise the ReadbackSubResource operation could
get stale data from the host buffer.
This allows the piglit arb_copy_buffer-subdata-sync test to pass when
we start using the SVGA3D_vgpu10_BufferCopy command.
v2: check the sbuf->dirty flag in the outer conditional, per Charmaine.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We previously could do blits with util_resource_copy_region() when doing
'loose' format checking. Also do blits with util_resource_copy_region()
when the blit src/dst formats (not the underlying resources) exactly
match. Needed for GL_ARB_copy_image.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
v2: remove extra svga_define_texture_level() call, per Charmaine.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Do texture->texture copies host-side with this command when possible.
Use the previous software fallback otherwise.
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We don't normally support rendering to SNORM surfaces, but with
GL_ARB_copy_image we can copy to them if we treat them as typeless
and use a UNORM surface view.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We previously handled the case of a RGBX sampler view of a RGBA surface.
Add the reverse case too. For GL_ARB_copy_image.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
For GL_ARB_copy_image we may be asked to create an RGBA view of
a RGBX surface. Use an RGBX view format for that case.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We want to be able to copy between different 32-bit, 3-channel surface
formats for GL_ARB_copy_image but since we don't support R32G32B32_FLOAT
for textures (it's not blendable and wouldn't work for render to texture)
we can't support 32-bit, 3-channel integer formats.
The state tracker will choose 4-channel formats instead.
Fixes the piglit arb_copy_image-format test for several cases.
Note: This change may need to be revisited if/when the texture_view exension
is enabled in driver.
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
This allows us to do copies between different, but compatible, surface
formats such as RGBA8_UNORM, RGBA8_SINT, RGBA8_UINT, etc. for
GL_ARB_copy_image.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
The VMware driver will use this for implementing GL_ARB_copy_image.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Since only the src box can have negative dims for flipping, just
comparing the src/dst box sizes is enough to detect flips.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Pulled out of the util_try_blit_via_copy_region() function. Subsequent
changes build on this.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.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>
Set when the stw_dev object's initialization is completed. We test
for this in the window callback function to avoid potential crashes
on start-up in multi-threaded applications.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Split the old stw_framebuffer_reference() function into two new
functions: stw_framebuffer_reference_locked() which increments
the refcount and stw_framebuffer_release_locked() which decrements
the refcount and destroys the buffer when the count hits zero.
Original patch by Jose. Modified by Brian (clean-ups, lock assertion
checks, etc).
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Otherwise we were leaking DC GDI objects and if wglBindTexImageARB()
was called enough we'd eventually hit the GDI limit of 10,000 objects.
Things started failing at that point.
v2: also release DC if we return early, per Charmaine.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This reverts commit 644e015f0b.
PrimitiveMode from the program doesn't always hold a valid value that
is neither of GL_TRIANGLES, GL_QUADS nor GL_ISOLINES when reaching
this code. This caused regressions in the following CTS tests:
GL44-CTS.stencil_texturing.functional
GL44-CTS.shading_language_420pack.binding_images
GL44-CTS.shading_language_420pack.binding_samplers
GL44-CTS.shading_language_420pack.binding_uniform_single_block
GL44-CTS.shading_language_420pack.implicit_conversions
GL44-CTS.shading_language_420pack.initializer_list
GL44-CTS.shading_language_420pack.length_of_vector_and_matrix
GL44-CTS.shading_language_420pack.line_continuation
Hence, we rather take it from the linked shader.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
There are two distinctly different uses of this struct. The first
is to store GL shader objects. The second is to store information
about a shader stage thats been linked.
The two uses actually share few fields and there is clearly confusion
about their use. For example the linked shaders map one to one with
a program so can simply be destroyed along with the program. However
previously we were calling reference counting on the linked shaders.
We were also creating linked shaders with a name even though it
is always 0 and called the driver version of the _mesa_new_shader()
function unnecessarily for GL shader objects.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
_mesa_write_shader_to_file() is only used to print gl shader objects
so Program should never be set as it only gets set for linked shaders.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
This will allow us to split gl_shader into two different structs, one for
shader objects and one for linked shaders.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Rather than passing in gl_shader we now pass in the IR. This will
allow us to later split gl_shader into two structs. One for use
as a linked per stage shader struct and one for use as a GL shader
object.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.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>
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>
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>
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>
