Issue by phaulos (MIGRATED)
Wednesday Apr 05, 2017 at 22:26 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1656

Noticed when writing CTS tests - validation errors didn't generate an error with this kind of a pattern (simplified):

VkImageCreateInfo imageInfo = { .initalLayout = VK_IMAGE_LAYOUT_UNDEFINED };
VkImage resolveImage = vkCreateImage(&imageInfo);
// allocate and bind memory
// start command buffer
// resolveImage still in VK_IMAGE_LAYOIUT_UNDEFINED
vkCmdResolveImage(dstImage = resolveImage, dstImageLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL);

Issue by krOoze (MIGRATED)
Monday May 01, 2017 at 21:43 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1724

core_validation layer uses obscure pLayerPrefix names like "DS", "DL", "MEM", ...

A) Does anybody know what these mean?

B) README.md where I looked for answer links to layers/vk_validation_layer_details.md. That document is non-existent.

C) It should be changed to something obvious. And it should at least contain the name of the source layer.

Issue by phaulos (MIGRATED)
Thursday Mar 09, 2017 at 22:22 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1549

dEQP-VK.spirv_assembly.instruction.compute.decoration_group.all is failing with:

ERROR: Type mismatch on descriptor slot 0.0 (used as type `ptr to uniform struct of (oddtype)`) but descriptor of type VK_DESCRIPTOR_TYPE_STORAGE_BUFFER (code 0x0000000d from SC at Unknown:2631)
...

Looking at the SPIR-V BufferBlock decoration is applied to 0.0 through OpGroupDecorate. This is not something glslang does so it might be that validation simply doesn't handle it.

Issue by DominikWitczakAMD (MIGRATED)
Monday Sep 25, 2017 at 11:08 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2088

Let X be an image defined as a FB attachment. Let X also be a partially-resident image.

Now, consider a renderpass with two subpasses:

• Subpass 1) renders to a color attachment which uses an image view whose parent image is X.
• Subpass 2) uses an input attachment which reads data rasterized in subpass 1.

Finally, let the renderpass use a DONT_CARE store op.

This use case could potentially be handled be differently by tilers and immediate renderers; one can imagine that tilers would use on-chip memory to store the rasterized contents, while the latter would stash the rendered data to image memory.

The issue arises if the writes, potentially only exercised by immediate renderers, touch pages without an actual physical memory backing. In such cases, it would be useful to have a validation check that would verify that all PRT tiles encapsulating the render area are actually backed by physical memory. If that is not the case, this could potentially lead to different results on different architectures.

The validation check would only be functional for mips that are not a part of miptails (because tile granularity breaks, as soon as we enter these), but it's probably better to warn developers about entering the "undefined behavior" land, rather than not letting them know about anything at all.

Issue by chrisforbes (MIGRATED)
Wednesday May 10, 2017 at 17:33 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1754

Issue by tobine (MIGRATED)
Monday Dec 19, 2016 at 15:52 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1285

With recent updates to spec synchronization, need to scrub semaphore validation to make sure that all valid usage cases are covered and correct. Also, while scrubbing, can make sure that unique error ids are in place for all semaphore checks.

Issue by ghost (MIGRATED)
Monday Oct 03, 2016 at 10:25 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1006

Certain pipeline stages can only perform a subset of the memory access operations that can be specified in the src/dstAccessMask of a Vk*MemoryBarrier structure. As an obvious example, "TOP_OF_PIPE" and "BOTTOM_OF_PIPE" do not perform any memory accesses.

Specifying a type of access with a stage that can't perform it will result in a no-op. I've seen a couple of apps attempting to use TOP/BOTTOM with memory accesses, which will not work. It would be nice to warn users that this is a no-op, as there's a higher-than-zero chance they're doing something they didn't intend to (or they are doing nothing and expecting something).

All stages other than "ALL_COMMANDS" and "ALL_GRAPHICS_COMMANDS" are affected by this. For instance, "DRAW_INDIRECT_BIT" will only ever perform accesses of type "VK_ACCESS_INDIRECT_COMMAND_READ_BIT", and no other stage will perform accesses of that type.

Issue by chrisforbes (MIGRATED)
Friday Sep 01, 2017 at 23:28 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2045

We're now more or less correct for CmdPushDescriptorSet, but not for the template variant.

Issue by haasn (MIGRATED)
Sunday Sep 17, 2017 at 05:21 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2071

In this code:

VkPresentModeKHR supported_modes[VK_PRESENT_MODE_RANGE_SIZE_KHR];
int num_modes = ARRAY_SIZE(supported_modes);
vkGetPhysicalDeviceSurfacePresentModesKHR(physd, surf, &num_modes, supported_modes);

I get an error as follows:

vkGetPhysicalDeviceSurfacePresentModesKHR() called with non-NULL pPresentModeCount; but no prior positive value has been seen for pPresentModeCount

But I believe common sense dictates that the number of supported swapchain modes can never exceed the number of swapchain modes. I think this warning is a bit too aggressive in cases like these.

Issue by tobine (MIGRATED)
Wednesday Aug 24, 2016 at 13:12 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#880

This is a tracking issue for some improvements that can be made to how descriptors are validated.

1. Pre-sort the std::map of descriptor bindings into an array after initial creation as the only subsequent use is to walk it in-order.
2. Implement test to demonstrate that bindings are correctly parsed in-order to correlate with appropriate dyn_offset_index (this was previously broken and have start of test in branch tobin_gh867_dyn_offset_test)
3. Add checks for physical limits such as maxUniformBufferRange
4. Error (or warn) if dynamic offset plus BufferInfo offset exceeds BufferInfo range? Currently only error if all three of these values exceed the underlying buffer range.

Issue by Berserker66 (MIGRATED)
Thursday Sep 28, 2017 at 21:54 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2093

In my case I have something like this:

https://pastebin.com/Z7UHMFny

Which unfortunately only tells me that something is wrong but does not actually help me in finding this issue. I logged the thread idents and slowly figured out that it must be my main thread and a thread that syncs the chromium embedded framework texture data. I'm still not sure what is actually happening and I'll need to invest some more time digging.

However, back to this issue - would it be possible to give a bit more information in these threading errors? Such as which command pool and which operations are happening at this time? Spec says, recording, freeing, resetting [...] - telling me which of these it is would already help.

Issue by tobine (MIGRATED)
Wednesday Oct 11, 2017 at 15:30 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2126

In VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER and VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER cases we need to make sure that if the memory backing the buffer is destroyed, that we flag an error. Definitely need to check at Draw time (which we already do for other buffer updates) but could also check this at update time.
It also appears that we don't verify backing memory for image updates. Need all of these checks.

Issue by ratchetfreak (MIGRATED)
Saturday Jul 02, 2016 at 13:13 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#723

https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/tests/layer_validation_tests.cpp#L3135

This test (RenderPassSubpassZeroTransitionsApplied) violates the following sentence of the spec:

Self-dependencies must only include pipeline stage bits that are graphics stages.

ALL_COMMANDS is not a graphics stage (or at least includes more than just graphics stages). Not to mention the created dependency includes all stages on both sides of the dependency which violates:

Self-dependencies must not have any earlier pipeline stages depend on any later pipeline stages. More precisely, this means that whatever is the last pipeline stage in srcStageMask must be no later than whatever is the first pipeline stage in dstStageMask (the latest source stage can be equal to the earliest destination stage).

This would also mean that ALL_GRAPHICS is not allowed because there is no way to make a sensible dependency with it.

Proposals for failing tests,

1. using a non-graphics stage in the masks like transfer or compute
2. using srcStageMask = Fragment and dst = Vertex (violating the order constraint)

Issue by yavn (MIGRATED)
Tuesday Dec 13, 2016 at 16:39 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1259

I'm observing errors related to keeping track of allocated memory and resource types that were bound to it. Layers are making assumptions about how the memory range is going to be used by the app and emit errors when the usage pattern seem to be incorrect.

1. Binding a memory range that was also bound to a resource with a different tiling

MEM(ERROR): object: 0xb type: 9 location: 0 msgCode: 3: Linear buffer 0xb is aliased with non-linear image 0x9 which is in violation of the Buffer-Image Granularity section of the Vulkan specification.

Although the layer is trying to highlight what is most likely a bug, there's no spec language (AFAIK) that says this is an error. Violating buffer-image granularity makes the resources alias each other, and aliasing of linear and non-linear resources makes reads/writes undefined to the other resource. So this should probably be a warning instead.

2. Mapping a memory range that is aliased with an unused image

DS(ERROR): object: 0x0 type: 0 location: 11197 msgCode: 6: Cannot map an image with layout VK_IMAGE_LAYOUT_UNDEFINED. Only GENERAL or PREINITIALIZED are supported.

MEM(ERROR): object: 0xf type: 10 location: 0 msgCode: 3: Non-linear image 0xf is aliased with linear image 0xcccccccccccccccc which is in violation of the Buffer-Image Granularity section of the Vulkan specification.

The layer is tracking bound memory ranges and sees that a range is used by an image that was never transitioned from UNDEFINED layout. But this message is a false positive. We're actually mapping the range in order to access a buffer that aliases the image. The image itself is never accessed. Of course there's no way to tell the intent, as this is not visible in the vkMapMemory call... Not sure if this can be improved. Again, layer is trying to do the right thing here, but in presence of aliasing this is just too ambiguous.

The second message outputs an uninitialized variable (0xcccccccccccccccc) because a common code is used that expects image handle but we only set memory range before calling. This is a small bug, not really relevant.

For reference, the Khronos internal Vulkan CTS issue for this is 560 if you want to see the test that causes these problems.

Issue by tobine (MIGRATED)
Tuesday Apr 25, 2017 at 16:41 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1697

This stems from a Pull request in android-vulkan-tutorials repo. @AlessandroBorges wants to update vulkan_wrapper, but changes really need to be made in the source generator which is not currently public.

This is a tracking issue to commit the vulkan_wrapper generator to this repo.

Issue by chrisforbes (MIGRATED)
Thursday May 25, 2017 at 17:20 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1817

There are a number of interesting spirv cases which glslang doesn't generate, but other toolchains can be expected to. We need to be able to write some tests in spirv assembly to exercise these.

Issue by qnope (MIGRATED)
Sunday Sep 03, 2017 at 14:15 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2048

I have an image in the VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL layout and when I am using it in a DescriptorImageInfo with a layout VK_IMAGE_LAYOUT_GENERAL. It is a mistake but Validation Layers don't tell me anything.

Issue by chrisforbes (MIGRATED)
Friday Dec 09, 2016 at 22:57 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1250

Issue by chrisforbes (MIGRATED)
Tuesday Jun 13, 2017 at 21:59 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1871

Spec says:

The layout of a structure type used as an Input or Output depends on whether it is also a Block (i.e. has a Block decoration).

If it is a not a Block, then the structure type must have a Location decoration. Its members are assigned consecutive locations in their declaration order, with the first member assigned to the location specified for the structure type. The members, and their nested types, must not themselves have Location decorations.

If the structure type is a Block but without a Location, then each of its members must have a Location decoration. If it is a Block with a Location decoration, then its members are assigned consecutive locations in declaration order, starting from the first member which is initially assigned the location specified for the Block. Any member with its own Location decoration is assigned that location. Each remaining member is assigned the location after the immediately preceding member in declaration order.

The locations consumed by block and structure members are determined by applying the rules above in a depth-first traversal of the instantiated members as though the structure or block member were declared as an input or output variable of the same type.

We're not quite doing this -- glslang doesn't generate all of these cases.

Issue by phaulos (MIGRATED)
Monday Mar 20, 2017 at 16:45 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1601

CTS test dEQP-VK.api.command_buffers.render_pass_continue is failing with:

ERROR: vkCmdClearAttachments(): The area defined by pRects[0] is not contained in the area of the current render pass instance. For more information refer to Vulkan Spec Section '17.2. Clearing Images Inside A Render Pass Instance' which states 'The rectangular region specified by a given element of pRects must be contained within the render area of the current render pass instance' (https://www.khronos.org/registry/vulkan/specs/1.0-extensions/xhtml/vkspec.html#vkCmdClearAttachments) (code 0x0000045b from DS at Unknown:1475)

It seems that the issue is that render area is not inherited from primary command buffer to the secondary buffer where vkCmdClearAttachments is issued.

Issue by karl-lunarg (MIGRATED)
Friday Aug 05, 2016 at 20:24 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#829

Just logging this as the result of some analysis from LunarXchange issue 305.

Some perf analysis shows that GetQueryPoolResults spends about 80% of its time creating the temporary unordered_map for very large query pools (e.g., thousands). Yes, this isn't an issue for smaller pools and creating the map certainly speeds up the subsequent validation operations. But this overhead can be too costly for some applications. (See LX 305 issue). We wonder if there is a way to avoid creating this map. Also, this general problem might be addressed in a future layers architecture where expensive tests can be disabled.

The issue can be reproduced fairly easily by modifying the occlusion_query sample app from the LunarG/VulkanSamples repo. Change the queryCount argument in vkCmdResetQueryPool to a large number like 16,000. (This is a missing validation check, btw) And comment out the call to vkQueueWaitIdle so that the CB with the queries is still in flight. The subsequent call to vkGetQueryPoolResults then runs slowly.

Note also that the implementation of std::unordered_map in VS 2013 has serious performance issues, which made the (implicit) free of the unordered_map take MUCH longer than desired. See http://stackoverflow.com/questions/21014822/very-slow-unordered-map-clearing. Moving to VS 2015 changed the cost of the free from 850 ms on VS 2013 to 7 ms on VS 2015 for a particular test. Since unordered_map is used a lot in the layers, this implies that using VS 2015 might help the perf of the VLs in a more general way.

Issue by tobine (MIGRATED)
Tuesday Aug 22, 2017 at 20:15 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2022

We had a previous perf warning for disturbed descriptors, along with associate test. Developers didn't like this perf warning (See #2020 ) so we removed it. As an enhancement, track disturbed descriptors and if a disturbed descriptor is used while unbound, note that it's unbound due to previously being disturbed.

Issue by DominikWitczakAMD (MIGRATED)
Thursday Jul 27, 2017 at 07:39 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1973

We recently received a bug report from ISV, which - after closer inspection - revealed that validation layers apparently do not check if the location decoration value specified in a SPIR-V blob exceeds the maximum number of output components in the VS shader stage reported as supported for a physical device that the shader module is used against.

In specific, let's consider the following:

OpDecorate %2680 Location 64

Our driver reports a value of (32*4) for maxVertexOutputComponents. Ignoring this restriction causes our vkCreateGraphicsPipeline() to crash.

The ISV claims they have been using validation layers and this condition has not been reported. Could you check if this use case is covered, please?

Issue by cnorthrop (MIGRATED)
Thursday Mar 09, 2017 at 23:07 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1551

The latest releases of the Android NDK (r14) and SDK Tools (25.3.1) are causing problems with our builds and tests.

If you've already upgraded, please roll back until we get them straightened out. I'll update this issue when things are working again with latest tools, either through source changes or tool updates.

Links to working versions below:

Android SDK Tools:
Windows - https://dl.google.com/android/repository/tools_r25.2.3-windows.zip
Linux - https://dl.google.com/android/repository/tools_r25.2.5-linux.zip
OSX - https://dl.google.com/android/repository/tools_r25.2.3-macosx.zip

Android NDK (13b known to work):
http://developer.android.com/ndk/downloads/older_releases.html

Issue by Jasper-Bekkers (MIGRATED)
Friday Jun 16, 2017 at 11:42 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1880

Hi,

Right now often you'll get validation errors like this Cannot submit cmd buffer using image (0x9a) [sub-resource: aspectMask 0x1 array layer 0, mip level 0], with layout .... In our engine we have a policy of naming all objects we create for debugging purposes so it would be extremely useful to pass these along to the validation layers for easier debugging so we can get a message like Cannot submit cmd buffer using image (LinearRenderTarget1) [sub-resource: aspectMask 0x1 array layer 0, mip level 0], with layout ... instead.

Can we make validation layers respect VK_EXT_debug_marker or have the validation layers expose some other kind of extension to provide names to it?

Issue by DominikWitczakAMD (MIGRATED)
Friday Oct 21, 2016 at 12:08 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1080

Consider an app which uses a renderpass attachment X both as a color & an input attachment in the same subpass. This triggers the following warnings:

However:

• The attachment cannot be in COLOR_ATTACHMENT_OPTIMAL layout because that's illegal as per spec.
• The attachment cannot be in READ_ONLY_OPTIMAL layout because of the same reason.
• The attachment cannot be in two layouts at once :)

Issue by tobine (MIGRATED)
Monday Mar 06, 2017 at 20:13 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1534

Refactor vkMapMemory() to follow the pre/post pattern where validation takes place during pre & state updates occur down post path.

Issue by haasn (MIGRATED)
Sunday Aug 20, 2017 at 23:14 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2015

By spec, it's required to submit two image barriers when moving a resource allocated with VK_SHARING_MODE_EXCLUSIVE from one queue family to another - one defining a “release” operation and the other defining an “acquire” operation.

However, in my current code, I noticed that I never fire a “release” operation - just an “acquire” operation in the receiving queue's command buffer. Despite this, I get no warning whatsoever from the validation layers.

Issue by tobine (MIGRATED)
Tuesday Jan 24, 2017 at 23:36 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1404

Received feedback that the error messages for incompatibility between descriptor layout and pipeline layout could be clearer. Need to make sure which components come from pipeline layout are clearly distinguished from the separate descriptor layout in the error message.

Issue by DominikWitczakAMD (MIGRATED)
Tuesday Aug 29, 2017 at 08:12 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2038

Let X be an universal queue (ie. a queue coming from a queue family that supports both compute and graphics ops).

Now, let's consider two command buffers:

1. Command buffer A which uses a renderpass with a single subpass. Within the subpass, a draw call is issued which triggers fragment shader invocations. The invocations use image store ops to write data to an image. The last command recorded to cmd buffer A sets event 1.
2. Command buffer B uses a compute shader which reads data via image load ops from the image as above. Before the dispatch call is made, the cmd buffer waits on event 1.

Both command buffers are submitted to the same universal queue.

For these cmd buffers to work as expected, an explicit subpass->external dependency is needed, because a) the implicit subpass->external dep does not include shader_write access mask, b) the modified image needs not be defined as a RP attachment.

Core Validation does not inform about this omission.

Issue by yavn (MIGRATED)
Friday Sep 23, 2016 at 13:37 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#974

This is a feature request.

It seems that Vulkan requires (similar to GLES) that PointSize is written in VS when the vertex pipeline is outputting points. It would be nice if layer could detect this situation and report an error if PointSize is not assigned to in the shader.

Please check the spec for details. From what I understood, this only applies if vertex shader is the only active vertex stage, and only if drawing points (VK_PRIMITIVE_TOPOLOGY_POINT_LIST). In other stages the point size is 1.0 by default and there are other rules (e.g. see shaderTessellationAndGeometryPointSize feature).

Issue by karl-lunarg (MIGRATED)
Sunday Aug 20, 2017 at 01:29 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2014

Obtained from the 2017 LunarG Ecosystem Survey

I'm not sure if you can easily validate this, but I ran into an issue when trying to copy QueryPool results. I was missing a memory transition that is required to get the results to actually copy into the buffer, but the validation layers didn't warn anything about it. Luckily the spec has wording that explained that I needed it to vkCmdCopyQueryPoolResults, but did not need to vkGetQueryPoolResults.

All Best Practices information is now tracked via the Vulkan-ValidationLayers project page. Please feel free to add cards to that project, or to create new issues for enhancements to Best Practices, so that we may add them to the project.

Thanks!

Issue by chrisforbes (MIGRATED)
Tuesday Jul 18, 2017 at 18:22 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1947

• descriptor_type_match needs to consider storage class of the declared variable, not just aspects of the type.
• mark_accessible_ids needs to consider the new StorageBuffer storage class.
• check VK extension is enabled if SPV extension is declared by the module (first case of this)
• intra-module validation that new storage class and new semantics are only used if the SPV extension is declared to be done by SPIRV-Tools (probably already complete)

Issue by chrisforbes (MIGRATED)
Wednesday Jul 06, 2016 at 21:57 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#731

Same idea as #604, but for FS outputs.

There are multiple things broken here:

• glslang gets confused about test code (see KhronosGroup/glslang#372)
• Nvidia gets confused and refuses to compile a correct shader which does this
• Validation didn't consider this case at all, producing spurious errors like #604.

Issue by wobakj (MIGRATED)
Tuesday Mar 14, 2017 at 22:08 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1580

On drawing, the following error is triggered: Descriptor in binding #0 at global descriptor index 1 is being used in draw but has not been updated
The error appears regardless of the actual value of the constant. No error is triggered when using a "normal" constant variable with identical value instead. This behaviour appears at least for sampler, texture and buffer arrays.

Issue by Jasper-Bekkers (MIGRATED)
Wednesday Sep 06, 2017 at 17:54 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2053

vkCmdCopyQueryPoolResults is considered to be a transfer operation, and its writes to buffer memory must be synchronized using VK_PIPELINE_STAGE_TRANSFER_BIT and VK_ACCESS_TRANSFER_WRITE_BIT before using the results.

This rule appears to slip through the validation layer causing incorrect timestamp query results on at least AMD hardware.

Could be a duplicate of #2014

Issue by chrisforbes (MIGRATED)
Tuesday Feb 28, 2017 at 04:44 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1510

Spec says load and store ops are ignored in this case, and the memory contents of the attachment are unmodified. However, we still currently validate everything, and drive the attachment to its finalLayout.

Issue by tobine (MIGRATED)
Thursday Nov 17, 2016 at 21:49 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1172

Smoketest has a buffer that is bound to memory without calling vkGetBufferMemoryRequirements(). The spec implies that this should not be done and there's a pending validation warning to flag this case. Understand smoketest behavior in this regard and update as appropriate.

Issue by DragoonX6 (MIGRATED)
Thursday Mar 09, 2017 at 19:36 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1544

I've been looking around a bit on the internet and I saw that there is no MinGW-w64 build of the Vulkan SDK. People have been suggesting using tools like dlltool to generate import libraries so you can at least link to it.

As this is far from optimal and stops people from doing source level debugging, I've been trying to get it to build with MSYS2's MinGW-w64 clang build.
This was relatively painless, however I did encounter a few minor issues, which I'll go into more detail below.
I did not check out the master branch, but the latest SDK tag, so I have no idea if master will be easier or harder to get working.

Most of the issues I encountered were missing casts for C++ compilers and some naive #ifdefs.
My current efforts have been slightly hacky, I've just been trying to get it to build, but I could submit it as a reference PR if you like.
Otherwise I could put in more effort to make a proper PR, as I haven't been building the tests either.
The tests don't build because Vulkan is shipping its own gtest and as far as I know MSYS2's gtest has been patched to work with MinGW-w64.

Issue by mathiasschott (MIGRATED)
Friday Aug 26, 2016 at 08:31 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#892

The application is constructing a VkDrawIndexedIndirectCommand buffer on host and then updating the device buffer with the data from host. This buffer is then used as the argument for an indirect draw. Missing a memory/buffer barrier in between those caused "issues"...

vkCmdUpdateBuffer
vkCmdPipelineBarrier // validation layer should report the lack of this call
vkCmdDrawIndirect

Issue by TiemoJung (MIGRATED)
Monday Jun 12, 2017 at 17:28 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1860

Hi,

while i was debugging our changes to our image state tracking system, i had a hard time figuring out which image mipmap level and/or array layer was not it the expected state, as the error message only lists the image aspect (as number, the name of that flag instead would be nice and consistent with the rest) and the current layout and the source layout of the barrier.
It would be helpful to add which mip levels and array layers are affected and may be the index of the barrier array passed to the barrier call.

Issue by cdwfs (MIGRATED)
Wednesday Jul 26, 2017 at 00:11 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1971

The checks in core_validation for vkGetQueryPoolResults():

• are too overzealous (reporting errors for usages not marked as invalid in the spec, such as retrieving the results of an unissued query with the WITH_AVAILABILITY flag set and the WAIT flag cleared)
• have ambiguous/duplicated report messages (same message for unavailable-and-unissued and unavailable-and-in-flight)
• have no VUIDs
• are, by their own admission, "insanely wasteful" (as reported in #829)

We should clean up the checks, and potentially clarify the spec regarding what is & isn't valid usage if we find something useful the layers aren't currently checking for.

Issue by Delwin9999 (MIGRATED)
Friday May 06, 2016 at 13:27 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#499

Some of this repository is in C, other parts are in C++. There are different headers necessary (inttypes.h vs. cinttypes) depending on what language you are compiling to.

Source files are already labels (.c vs *.cpp). I suggest that headers likewise be labelled (.h vs. *.hpp) whereas currently all headers are *.h.

Issue by szdarkhack (MIGRATED)
Friday Dec 02, 2016 at 13:29 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1225

In the current implementation of core validation, when a WSI fence is retired it is not associated with any queue and thus does not retire any work, leading to incorrect errors about resources being in use when in fact they are not. It should be the case that when an acquire fence is waited upon for a particular image index, all previous work for which the respective presentation submission waited should in turn be retired. For instance:

render loop
acquire image and wait on fence
submit work that signals a semaphore
queue present that waits upon that semaphore
end render loop

It should be the case that when the acquire fence is signaled the presentation must have finished, and as such the work submitted prior to the presentation (to the same image index) must also have finished. Therefore, resources used by that submission should be marked as not being in flight (command buffers etc).

Issue by tobine (MIGRATED)
Friday Sep 29, 2017 at 18:49 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2094

Src probably shouldn't need to be updated. Need some more spec language and potentially new VUIDs around copy update cases, currently primarily copy/reuse write update VUIDs. Add more copy update testing as well.

Issue by jeremy-lunarg (MIGRATED)
Friday May 19, 2017 at 20:34 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1793

If I set VK_ICD_FILENAMES (e.g. /etc/vulkan/icd.d/nvidia_icd.json), then the Environment Variable Path Test in run_loader_tests.sh will fail. I don't believe this is intended behavior, but I may be mistaken.

Issue by DominikWitczakAMD (MIGRATED)
Friday Sep 23, 2016 at 13:32 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#973

Consider a command buffer A which does the following:

1. Start a renderpass X
2. Draw stuff.
3. End renderpass X
4. Start a renderpass Y
5. Draw even more stuff
6. End renderpass Y.

Renderpasses X and Y use the same attachment. For this command buffer to be correct, the renderpasses need to be synchronized via an event or external dependency. The problem is ignored by core validation layer.

Issue by chrisforbes (MIGRATED)
Friday May 19, 2017 at 16:57 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1788

Currently we have parallel mechanisms here.

Issue by Novum (MIGRATED)
Tuesday Oct 03, 2017 at 21:45 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2100

I understand that some performance degradation is expected, but with a lot of API calls the performance even with only core validation is unworkable. We are talking <1FPS where we would easily manage >200FPS on CPU side otherwise.