| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For 0 timeout, just poll for an event, and if none, return
For UINT64_MAX timeout, just wait for special event blocked
For other timeouts get the xcb fd and block on it, decreasing
the timeout if we get woken up for non-special events.
v1.1: return VK_TIMEOUT for poll timeouts.
handle timeout going negative.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 787c172aed0ae88ca6a8c1a193d9dd744fbdc918)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 750d8cad72a for vkGetPhysicalDeviceSurfaceFormatsKHR, which was suffering
from the same problem.
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
(cherry picked from commit b677b99db5c48ffd1eeef538b962080ac5fd65d9)
Nominated-by: Emil Velikov <emil.velikov@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x11_surface_get_formats() is currently asserting that the number of
elements in pSurfaceFormats must be greater than or equal to the number
of formats available. This is buggy because pSurfaceFormatsCount
elements are later copied from the internal formats' array, so if
pSurfaceFormatCount 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 579 of the PDF:
"If pSurfaceFormats is NULL, then the number of format pairs supported
for the given surface is returned in pSurfaceFormatCount. Otherwise,
pSurfaceFormatCount must point to a variable set by the user to the
number of elements in the pSurfaceFormats array, and on return the
variable is overwritten with the number of structures actually written
to pSurfaceFormats. If the value of pSurfaceFormatCount is less than
the number of format pairs supported, at most pSurfaceFormatCount
structures will be written. If pSurfaceFormatCount is smaller than
the number of format pairs 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 pSurfaceFormatCount is greater than the
internal number of formats, it is clamped to that many formats. But
if it is lesser than that, then pSurfaceFormatCount elements are copied,
and the call returns VK_INCOMPLETE.
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 750d8cad72a532d977df10ffbbdd1902bd06f50b)
Nominated-by: Emil Velikov <emil.velikov@collabora.com>
Squashed with commit:
vulkan/wsi/x11: Smplify implementation of vkGetPhysicalDeviceSurfaceFormatsKHR
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>
(cherry picked from commit 129da274261b6e79f459e24428591f137bf92ed1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the spec for vkGetPhysicalDeviceImageFormatProperties:
"If format is not a supported image format, or if the combination of format,
type, tiling, usage, and flags is not supported for images, then
vkGetPhysicalDeviceImageFormatProperties returns VK_ERROR_FORMAT_NOT_SUPPORTED."
Makes the following Vulkan CTS tests report 'Not Supported' instead of crashing:
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_unorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_snorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_uscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_sscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_uint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_sint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_unorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_snorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_uscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_sscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_uint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_sint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r4g4_unorm_pack8
dEQP-VK.api.image_clearing.clear_color_image.1d_r8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r8g8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r8g8b8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_b5g5r5a1_unorm_pack16
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit 35deeda66f5fcbccb24f8eda42c8a4f67bb106c9)
Squashed with:
anv/format: handle unsupported formats earlier
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 277f868e6682b9ee398ed326425274c3d1898417)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Driver should enumerate only up-to min2(num_available, num_requested)
properties and return VK_INCOMPLETE if the # of requested props is
smaller than the ones available.
Presently we assert out in such cases.
Inspired by a similar fix for RADV.
v2: Use MIN2 + typed_memcpy (Jason).
Should fix: dEQP-VK.api.info.device.extensions
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 5cc07d854c85e30c5aa1ced626b4b6500f8cd74c)
|
|
|
|
|
|
|
|
|
|
|
| |
There is no version 2 of the DRI2_FENCE extension. So only a request
for version 1 has a chance to succeed.
Fixes: 74b1969d717f (gbm: wire up fence extension)
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit d9a3ad94cac34c51603660af6647290d238f64bc)
|
|
|
|
|
|
|
| |
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit f680a01ad4ed360b44cd1b9d3c447a95cedbccd5)
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we try to allocate a binding table and fail, we have to get a new
binding table block, re-emit STATE_BASE_ADDRESS, and then try again. We
already handle this correctly for 3D and blorp but it never got handled for
CS. This fixes the new stress.lots-of-surface-state.cs.static crucible test.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 722ab3de9f0e30e1dfbbd2b5217330b85f53bcec)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since both pCreateInfo->strideInBytes and pCreateInfo->extent.height
are of uint32_t type 32-bit arithmetic will be used.
Fix unintentional integer overflow by casting to uint64_t before
multifying.
CID 1394321
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
[Emil Velikov: cast only of the arguments]
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit e074a08a6ded3260f13111d0e23961dea2da2442)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're missing the close() to the matching open().
CID 1373407
v2: Fixes from Emil Velikov's review
Update the teardown in reverse order of the setup/init.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> (v1)
(cherry picked from commit 69cc7d90f9f60d95cd570a4e87755a474554d41f)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes:
ES31-CTS.functional.texture.border_clamp.formats.depth24_stencil8_sample_stencil.nearest_size_pot
ES31-CTS.functional.texture.border_clamp.formats.depth24_stencil8_sample_stencil.nearest_size_npot
ES31-CTS.functional.texture.border_clamp.formats.depth32f_stencil8_sample_stencil.nearest_size_pot
ES31-CTS.functional.texture.border_clamp.formats.depth32f_stencil8_sample_stencil.nearest_size_npot
ES31-CTS.functional.texture.border_clamp.unused_channels.depth24_stencil8_sample_stencil
ES31-CTS.functional.texture.border_clamp.unused_channels.depth32f_stencil8_sample_stencil
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 44c5ed02d1b173c061c3188e245d384fd4c0abba)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conditional emit
Consider a geometry shader that contains code like this:
some_out = expr;
if (cond) {
...
EmitVertex();
} else {
...
EmitVertex();
}
Both branches should see the correct value of some_out.
Since this is a rather subtle and rare case, I'm submitting a piglit test
for this as well.
GLSL says that the values of output variables are undefined after
EmitVertex(). With this change, the values will now be defined and
unmodified. This may reduce optimization opportunities in the probably
quite rare case where subsequent compiler passes cannot prove that the
value of the output variable is overwritten.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 0d383a79a8f13bb00ed5e5d84f41071b43c7e92d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For compute shaders, we free the selector after the shader has been
compiled, so we need to save this bit somewhere else. Also, make sure that
this type of bug cannot re-appear, by NULL-ing the selector pointer after
we're done with it.
This bug has been there since the feature was added, but was only exposed
in piglit arb_compute_variable_group_size-local-size by commit
9bfee7047b70cb0aa026ca9536465762f96cb2b1 (which is totally unrelated).
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 42d5e91a2ae235c007c5d17935be9bb1c4ff388e)
|
|
|
|
|
|
|
|
| |
Fixes around 60 Vulkan CTS tests on Haswell
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit a8b85f1f772ef45cdeba9d5d205d105e689c3bdf)
|
|
|
|
|
|
|
|
|
|
|
| |
The translation to llvm was failing here due to required lod.
This fixes some new SteamVR shaders.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit b1340fd708bb873617b8a529ac45cbc9507bd6c4)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the image view for sampling just the depth.
It removes some pointless swizzle code, and adds
a missing case for the x8_d24 format.
Fixes:
dEQP-VK.renderpass.formats.d32_sfloat_s8_uint.input.*
dEQP-VK.renderpass.formats.d24_unorm_s8_uint.input.*
dEQP-VK.renderpass.formats.x8_d24_unorm_pack32.input.*
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 6d7be52d90cd5f4798b9612e8a68f6d6d9e31c33)
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes 9 of the
dEQP-VK.renderpass.attachment_allocation.input_output.*
tests.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 51a44c0021398177d56f86b7fb8d63673186a380)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We weren't taking first_component into account when handling GS push
inputs. We hardly ever push GS inputs, so this was not caught by
existing tests. When I started using component qualifiers for the
gl_ClipDistance arrays, glsl-1.50-transform-feedback-type-and-size
started catching this.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit c4be6e0b8d91746eccf334b9e20861af4036d06a)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case we have empty log (""), we should return 0. This fixes
Khronos WebGL conformance test 'program-infolog'.
From OpenGL ES 3.1 (and OpenGL 4.5 Core) spec:
"If pname is INFO_LOG_LENGTH , the length of the info log, including
a null terminator, is returned. If there is no info log, zero is
returned."
v2: apply same fix for get_shaderiv and _mesa_GetProgramPipelineiv (Ian)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> (v1)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97321
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit ec4e71f75e9b8a1c427994efa32a61593e3172f9)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNU/Hurd does not define PATH_MAX since it doesn't have such arbitrary
limitation, so this failed to compile. Apparently glibc does not
enforce PATH_MAX restrictions anyway, so it's kind of a hoax:
https://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html
MSVC uses a different name (_MAX_PATH) as well, which is annoying.
We don't really need it. We can simply asprintf() the filenames.
If the filename exceeds an OS path limit, presumably fopen() will
fail, and we already check that. (We actually use ralloc_asprintf
because Mesa provides that everywhere, and it doesn't look like we've
provided an implementation of GNU's asprintf() for all platforms.)
Fixes the build on GNU/Hurd.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98632
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 9bfee7047b70cb0aa026ca9536465762f96cb2b1)
[Emil Velikov: s|prog->Id|base->Id|]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/mesa/main/arbprogram.c
|
|
|
|
|
|
|
|
|
| |
Fixes crashes when starting Deus Ex: Mankind Divided.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
(cherry picked from commit ca76e6b5213c92432b9f3a641cb26f5861d53e09)
|
|
|
|
|
|
|
|
|
| |
Otherwise, we'll try to clear it the first time it's used as a draw so if
you do some multisampled rendering, resolve to an attachment, and then draw
on top of the single-sampled attachment, we might accidentally clear it.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit ccdf9af39265ef3478fac4d13b19e9d17fbbcab7)
|
|
|
|
|
|
|
|
|
|
|
| |
Before, we were always treating it as an output which bogus. The only
stage in which this it can be an output is the geometry stage. In all
other stages, it's an input which, in the back-end, we actually want to be
a system value.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 955714759257e81f01f013c84d2bd7f14a0ec04f)
|
|
|
|
|
|
| |
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 1c97432ce88ea272ff7d906cd36f70e09dafcab9)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bunch of new CTS tests which look for exactly this. Even in
the cases where we just call vk_free to free a CPU data structure, we still
handle NULL explicitly. This way we're less likely to forget to handle
NULL later should we actually do something less trivial.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 49f08ad77f51cc344e4bfe60ba9f8d9fccfbd753)
[Emil Velikov: color_rt_surface_state is still around]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/intel/vulkan/anv_image.c
|
|
|
|
|
|
|
|
|
|
|
| |
v2: s/bdw/gen; Add the 2x6 config
v3: Add min_ds_entries
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 2193fb0e1f437b53672a03f74e40d4aebc503f9e)
|
|
|
|
|
|
|
|
|
| |
This fixes a number of CTS tests like:
dEQP-VK.glsl.texture_gather.basic.2d.rgba8ui.size_npot.clamp_to_edge_repeat
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 713522fb8d4366d29be18edc3d5f33faba1cb7c4)
|
|
|
|
|
|
|
|
|
|
| |
Just return if the passed in swapchain is NULL.
Fixes: dEQP-VK.wsi.xlib.swapchain.destroy.null_handle
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 38ab625c5f5ca06b78af2892422a966dc659f8cd)
|
|
|
|
|
|
|
|
|
|
| |
This fixes the x11 and wayland backends to not assert:
dEQP-VK.wsi.xcb.swapchain.get_images.incomplete
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 253fa25d09b77e18f736b97da07d57be0e6c4200)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No known fixed tests, but it looks like a typo from:
commit 8ac99eabb6570f0f3c5f7d7da1332a99ce636362
intel/isl: Add a helper for getting the size of an interleaved pixel
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 0ac57afa6fbe59e9fd8eef38365cb3da8ec67f95)
|
|
|
|
|
|
|
|
|
| |
This was missing.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
(cherry picked from commit 341fc0073a3c05fd43e9c7a33613bcb881f25f33)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A commit from the CTS suite on the 1.0-dev branch started using
VK_REMAINING_MIP_LEVELS, we're not dealing with it properly for clears.
Fixes:
dEQP-VK.api.image_clearing.clear_color_image.*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit a46bc3f70a22a71dc2977f7394841e1b19bb68b6)
|
|
|
|
|
|
|
|
| |
I had this exactly backwards, but apparently the piglit tests were all
landing in r0-r3 anyway.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 977d8b526b983c8d19df00af224033389f8ab7c8)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 2e2562cabbe9a1d3fb997ccaccc20ba31b2006c3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows for gl_PrimitiveId to come in as a system value rather than as
an input. This is the way it will come in from SPIR-V. We keeps the input
path working for now so we don't break GL.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit a5e88e66e633aaeb587b274d80e21cd46c8ee2cb)
[Emil Velikov: nir_shader::info is not a pointer in branch]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From the Vulkan spec 1.0.32 section 29.6 docs for vkAcquireNextImageKHR:
"Let n be the total number of images in the swapchain, m be the value of
VkSurfaceCapabilitiesKHR::minImageCount, and a be the number of
presentable images that the application has currently acquired (i.e.
images acquired with vkAcquireNextImageKHR, but not yet presented with
vkQueuePresentKHR). vkAcquireNextImageKHR can always succeed if a ≤ n -
m at the time vkAcquireNextImageKHR is called. vkAcquireNextImageKHR
should not be called if a > n - m with a timeout of UINT64_MAX; in such
a case, vkAcquireNextImageKHR may block indefinitely."
With minImageCount == 2 (as it was previously, the client is allowed to
acquire all but one image withoutblocking. If we really need 4 images for
mailbox mode + pageflipping, then we need to request a minimum of 4 images
up-front. This is a bit unfortunate because it means we will always
consume 4 images. In the future, we may be able to optimize this a bit by
waiting until the server starts to flip and returning OUT_OF_DATE to get
the client to re-allocate with more images or something like that.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 4fa0ca80eeeac813affcbb0129ed61f1534d8df0)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can only read the valid samples if this is an MSAA
texture, which means the type field must be 0x14 or 0x15.
This fixes:
dEQP-VK.glsl.texture_functions.query.texturesamples.*
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 2de85eb97ab2ef45ec23f694a566cd0ec8192885)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows a more reasonable error message for '#version 0' of
0:1(10): error: GLSL 0.00 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES
instead of
0:1(10): error: syntax error, unexpected $undefined, expecting INTCONSTANT
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97420
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: mesa-stable@lists.freedesktop.org
Cc: Juan A. Suarez Romero <jasuarez@igalia.com>
Cc: Karol Herbst <karolherbst@gmail.com>
(cherry picked from commit c8c46641af43edd106528ac0293db5aa02a2364e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The #version directive can only handle decimal constants. Enforce that
the value is a decimal constant.
Section 3.3 (Preprocessor) of the GLSL 4.50 spec says:
The language version a shader is written to is specified by
#version number profile opt
where number must be a version of the language, following the same
convention as __VERSION__ above.
The same section also says:
__VERSION__ will substitute a decimal integer reflecting the version
number of the OpenGL shading language.
Use a separate flag to track whether or not the #version line has been
encountered. Any possible sentinel (0 is currently used) could be
specified in a #version directive. This would lead to trying to
(internally) redefine __VERSION__. Since there is no parser location
for this addition, NULL is passed. This eventually results in a NULL
dereference and a segfault.
Attempts to use -1 as the sentinel would also fail if '#version
4294967295' or '#version 18446744073709551615' were used. We should
have piglit tests for both of these.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97420
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: mesa-stable@lists.freedesktop.org
Cc: Juan A. Suarez Romero <jasuarez@igalia.com>
Cc: Karol Herbst <karolherbst@gmail.com>
(cherry picked from commit e85a747e294762785df2ce8a299c153254c6fca2)
|
|
|
|
|
|
|
|
|
| |
This gets rid of all the memory leaks reported by the WSI CTS tests.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 302f641d14f5c4d1560b6a0170803e21bd4bb976)
|
|
|
|
|
|
|
|
| |
We use pthreads and, for some reason, it wasn't getting included
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 3b6abfc69ac485006cbedba7bcad234888cad44f)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our previous fence implementation was very simple. Fences had two states:
signaled and unsignaled. However, this didn't properly handle all of the
edge-cases that we need to handle. In order to handle the case where the
client calls vkGetFenceStatus on a fence that has not yet been submitted
via vkQueueSubmit, we need a three-status system. In order to handle the
case where the client calls vkWaitForFences on fences which have not yet
been submitted, we need more complex logic and a condition variable. It's
rather annoying but, so long as the client doesn't do that, we should still
hit the fast path and use i915_gem_wait to do all our waiting.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 843775bab78a6b4d5cb4f02bd95d9d0e95c1c5e3)
|
|
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 73701be667ae408772bf20cb504b70d1775d4a4b)
|
|
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 71397042fea36a2a14b530b75829ad13f969fd00)
|
|
|
|
|
|
|
| |
Fixes piglit glsl-fs-shadow2D-clamp-z.
Cc: <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 08d51487e3b8cfb14ca2ece9545b2e2ed344e3cc)
|
|
|
|
|
|
|
|
|
|
| |
It's much better to just skip the draw call entirely. Getting this
information out of register allocation will also be useful for
implementing threaded fragment shaders, which will need to retry
non-threaded if RA fails.
Cc: <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 4d019bd703e7c20d56d5b858577607115b4926a3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a port of commit a4a59172482d50318a5ae7f99021bcf0125e0f53:
Add guards to prevent dereferencing NULL dynamic pipeline state. Asserts
of pCreateInfo members are moved to the earliest points at which they
should not be NULL.
This fixes a segfault, related to pColorBlendState, seen in Talos Principle
which I've observed after startup is completed and when exiting the menus,
depending on when Vulkan rendering is selected.
v2: moved the NULL check in radv_pipeline_init_blend_state to after the
declarations.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 9b121512ac0f78d0996613664b456005d88370d2)
|
|
|
|
|
|
|
|
|
|
| |
In the event that multiple threads attempt to install a graph
concurrently, protect the shared list.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
(cherry picked from commit 381edca826ee27b1a49f19b0731c777bdf241b20)
|
|
|
|
|
|
|
|
|
| |
We're missing the closedir() to the matching opendir().
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
(cherry picked from commit 5a58323064b32442e2de23c95642bc421be696f8)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of trying to maintain a reference counted list of valid HUD
objects, and freeing them accordingly, creating race conditions
between unanticipated multiple threads, simply accept they're
allocated once and never released until the process terminates.
They're a shared resource between multiple threads, so accept
they're always available for use.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
(cherry picked from commit 6ffed086795aaa84ab35668bb59d712cdde34da3)
|