this fixes some of the regressions with
"ralloc: remove memset from ralloc_size"
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Switch to use memory allocations which zero memory for places
where needed.
v2: modify and rebase on top of Marek's series (Tapani)
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
time GALLIUM_NOOP=1 ./run shaders/private/alien_isolation/ >/dev/null
Before (2 takes):
real 0m8.734s 0m8.773s
user 0m34.232s 0m34.348s
sys 0m0.084s 0m0.056s
After (2 takes):
real 0m8.448s 0m8.463s
user 0m33.104s 0m33.160s
sys 0m0.088s 0m0.076s
Average change in "real" time spent: -3.4%
calloc should only do 2 things compared to malloc:
- check for overflow of "n * size"
- call memset
I'm not sure if that explains the difference.
v2: clear "parent" and "next" in the caller of add_child.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> (v1)
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> (v1)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
The options specified in the CLOVER_EXTRA_BUILD_OPTIONS shell
variable are appended to the options specified by the OpenCL program
in the clBuildProgram function call, if any.
Analogously, the options specified in the CLOVER_EXTRA_COMPILE_OPTIONS
and CLOVER_EXTRA_LINK_OPTIONS variables are appended to the options
specified in clCompileProgram and clLinkProgram function calls,
respectively.
v2:
* rename to CLOVER_EXTRA_COMPILER_OPTIONS
* use debug_get_option
* append to linker options as well
v3: code cleanups
v4: separate CLOVER_EXTRA_LINKER_OPTIONS options
v5:
* fix documentation typo
* use CLOVER_EXTRA_COMPILER_OPTIONS in link stage
v6:
* separate in CLOVER_EXTRA_{BUILD,COMPILE,LINK}_OPTIONS
* append options in cl{Build,Compile,Link}Program
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by[v1]: Edward O'Callaghan <funfunctor@folklore1984.net>
v7 [Francisco Jerez]: Slight simplification.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
OpenCL apps can quote arguments they pass to the OpenCL compiler, most
commonly include paths containing spaces.
If the Clang OpenCL compiler was called via a shell, the shell would
split the arguments with respect to to quotes and then remove quotes
before passing the arguments to the compiler. Since we call Clang as a
library, we have to split the argument with respect to quotes and then
remove quotes before passing the arguments.
v2: move to tokenize(), remove throwing of CL_INVALID_COMPILER_OPTIONS
v3: simplify parsing logic, use more C++11
v4: restore error throwing, clarify a comment
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
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>
Commit 66fcfa6894 changed the vec4 version of offset() to have 3
parameters instead of 2 but the vec4_cmod_propagation test was never
updated.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
When blending with GL_COLORBURN_KHR and these colors:
dst = <0.372549027, 0.372549027, 0.372549027, 0.372549027>
src = <0.09375, 0.046875, 0.0, 0.375>
the normalized dst value became 0.99999994 (due to precision problems
in the floating point divide of rgb by alpha). This caused the color
burn equation to fail the dst >= 1.0 comparison. The blue channel would
then fall through to the dst < 1.0 && src >= 0 comparison, which was
true, since src.b == 0. This produced a factor of 0.0 instead of 1.0.
This is an inherent numerical instability in the color burn and dodge
equations - depending on the precision of alpha scaling, the value can
be either 0.0 or 1.0. Technically, GLSL floating point division doesn't
even guarantee that 0.372549027 / 0.372549027 = 1.0. So arguably, the
CTS should allow either value. I've filed a bug at Khronos for further
discussion (linked below).
In the meantime, this patch improves the precision of alpha scaling by
replacing the division with (rgb == alpha ? 1.0 : rgb / alpha). We may
not need this long term, but for now, it fixes the following CTS tests:
ES31-CTS.blend_equation_advanced.blend_specific.GL_COLORBURN_KHR
ES31-CTS.blend_equation_advanced.blend_all.GL_COLORBURN_KHR_all_qualifier
Cc: currojerez@riseup.net
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16042
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The term "client array" is a legacy thing dating back to the pre-VBO
era when _all_ vertex arrays lived in client memory.
Nowadays, it only contains vertex array state which is derived from
gl_array_attributes and gl_vertex_buffer_binding. It's used by the
VBO module and some drivers.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This patch simplifies x11_surface_get_formats(). It is actually just a
readability improvement over the patch I provided earlier this week
(750d8cad72).
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
x11_surface_get_present_modes() is currently asserting that the number of
elements in pPresentModeCount must be greater than or equal to the number
of present modes available. This is buggy because pPresentModeCount
elements are later copied from the internal modes' array, so if
pPresentModeCount is greater, it will overflow it.
On top of that, this assertion violates the spec. From the Vulkan 1.0
(revision 32, with KHR extensions), page 581 of the PDF:
"If the value of pPresentModeCount is less than the number of
presentation modes supported, at most pPresentModeCount values will be
written. If pPresentModeCount is smaller than the number of
presentation modes supported for the given surface, VK_INCOMPLETE
will be returned instead of VK_SUCCESS to indicate that not all the
available values were returned."
So, the correct behavior is: if pPresentModeCount is greater than the
internal number of formats, it is clamped to that many present modes. But
if it is lesser than that, then pPresentModeCount elements are copied,
and the call returns VK_INCOMPLETE.
This fix is similar (but simpler and more readable) than the one I provided
in 750d8cad72 for vkGetPhysicalDeviceSurfaceFormatsKHR, which was suffering
from the same problem.
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
An assert is currently raised, preventing decompression of a texture image into
a GL_TEXTURE_3D target. I have not found any spec wording that would explain
this, or implementation detail that would prevent it. And in any case, the
driver should not cause a crash upon user input arguments.
Fixes most failing subcases in CTS tests:
* GL44-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
* GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
These tests were crashing the driver before. Now they just fail, but due
to an unrelated issue affecting 2 out of the 45 test subcases.
No regressions observed against piglit or CTS-GL.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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>
Advertise two device local memory heaps; one that is host visible
and one that is not.
This makes it possible for clients to tell how much host visible
vs. non-host visible memory is available.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add the new memory type between the two device-local types. This makes
the list of supported memory types look like this:
1) DEVICE_LOCAL | | |
2) | HOST_VISIBLE | HOST_COHERENT |
3) DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT |
4) | HOST_VISIBLE | HOST_COHERENT | HOST_CACHED
With this order a client that searches for a HOST_VISIBLE and
HOST_COHERENT memory type using the algorithm described in section
10.2 of the Vulkan specification (revision 32) will find the host-
local memory type first.
A client that requires the memory type to be HOST_VISIBLE and
HOST_COHERENT, but not DEVICE_LOCAL is most likely searching for
a memory type suitable for staging buffers / images.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These restrictions existed because intel_miptree_blit couldn't handle
surfaces bigger than 32k. How that we're chopping blits up into chunks, it
can handle any size we throw at it so we can get rid of this restriction.
This improves the terrain tests in synmark by 25-30% on my Sky Lake gt3.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reported-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This allows us to blit much larger images than if we use the blitter
directly. In particular, it gives us an almost infinite image height
compared to the fairly limiting 32k. We do, however, still have a
restriction on stride of the image because handling larger strides, while
possible, is fairly difficult.
v2: Properly handle linear blit alignment restrictions
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This assertion, while valid for linear buffers, doesn't work properly for
tiled memory. It used to work most of the time because the offset provided
was always to the left-hand edge of the image. However, if you use a byte
offset to get to the inside of the image, the height * stride calculation
may actually end up being too large.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The only actual user of this parameter was blorp and, since the conversion
to ISL, it no longer uses this function.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
With dealing with rectangles in compressed images, you can have a width or
height that isn't a multiple of the corresponding compression block
dimension but only if that edge of your rectangle is on the edge of the
image. When we call convert_to_single_slice, it creates an 2-D image and a
set of tile offsets into that image. When detecting the right-edge and
bottom-edge cases, we weren't including the tile offsets so the assert
would misfire. This caused crashes in a few UE4 demos
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reported-by: "Eero Tamminen" <eero.t.tamminen@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98431
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Tested-by: "Eero Tamminen" <eero.t.tamminen@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
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>
When checking if a type contains doubles, integers, samples, etc. we
check if the current type is a record or array, but not if it is an
interface.
This commit also inspects if the type is an interface.
It fixes spec/arb_enhanced_layouts/compiler/transform-feedback-layout-qualifiers/xfb_offset/invalid-block-with-double.vert
piglit test.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
So that it has the same semantics as the scalar backend implementation. The
helper will now take a simd width (which is always 8 in vec4 mode) and step
as many scalar components as specified by that width, respecting the size of
the scalar channels.
v2 (Curro):
- Remove the assertion in offset(), byte_offset() has the same checks.
- Use byte_offset() directly instead of add_byte_offset().
- Make things more clear by explicitly including the vertical stride
in the byte offset expression.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
In a later patch we want to change the semantics of offset() to be in terms
of SIMD width and scalar channels so it is consistent with the definition
of the same helper in the scalar backend. However, some uses of offset()
in the vec4 backend do not operate naturally in terms of these
semantics. In these cases it is more natural to use the byte_offset() helper
instead.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
v2: wrap the helper in a namespace to make clear that it is an
implementation detail of byte_offset() and is not intended
to be used independently (Curro).
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
SSO validation and other program interface queries want to see that
unsized (non-patch) TCS output/TES input arrays are implicitly sized
to gl_MaxPatchVertices.
By the time we create the program resource lists, we've sized the arrays
to their actual size. (We try to create TCS output arrays to match the
output patch size right away, and at this point, we should have shrunk
TES input arrays.) One option would be to keep them sized to
gl_MaxPatchVertices, and defer shrinking them. But that's a big change,
and I don't think it's a good idea.
Instead, this patch introduces a new ir_variable flag which indicates
the variable is implicitly to gl_MaxPatchVertices. Then, the linker
munges the types when creating the resource list, ignoring the size
in the IR's types. Basically, lie about it for resource queries.
It's ugly, but I think it ought to work.
We probably could use var->data.implicit_sized_array for this, but
I opted for a separate bit to try and avoid convoluting the existing
SSBO handling. They're similar in concept, but share none of the
same code...
Fixes:
ES31-CTS.core.tessellation_shader.single.xfb_captures_data_from_correct_stage
and the ES32-CTS and ESEXT-CTS variants.
v2: Add a comment (requested by Timothy, written by me).
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
The next commit will use this in add_shader_variable - this just
separates out some of the mechanical changes for easier review.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Otherwise we can end up with mismatching behavior between config and
surface when client queries surface attributes. As example, configs
for DRI3 do not support preserved behavior but here we were setting
preserved behavior for pixmap and pbuffer.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98326
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Tested-by: Mark Janes <mark.a.janes@intel.com>
commit 85008db1d5 missed this enum
for GL_KHR_robustness implementation
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
EGL specification requires context to be current only when sync
type matches EGL_SYNC_FENCE_KHR.
Fixes 25 failing dEQP tests:
dEQP-EGL.functional.reusable_sync.*
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98339
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
We shouldn't be using ASYNC here, that would be used
for immediate mode, so let's implement that.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just moves this up a level as x11 will need it to
implement things properly.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
