Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vkCmdBeginTransformFeedbackEXT validation failed when counterBufferCount == 0 #480

Closed
jasuarez opened this issue Nov 12, 2018 · 2 comments
Closed
Assignees
Milestone

Comments

@jasuarez
Copy link
Contributor

ValidationLayers is complaining about counterBufferCount must be greater than 0 in a call like:

vkCmdBeginTransformFeedbackEXT(*cmdBuffer, 0, 0, DE_NULL, DE_NULL);

Vulkan 1.1.91 does not explicitly states that counterBufferCount must be greater than 0. Rather it says that it is the size of pCounterBuffers, and this can be NULL. Thus, counterBufferCount should be 0.

Similar issue applies for vkCmdEndTransformFeedbackEXT.

@jzulauf-lunarg
Copy link
Contributor

Triage notes: codegen appears to be correctly interpreting the vk.xml that tags counterBufferCount as optional=false. The registry looks to be inconsistent with the spec. @mikes-lunarg -- can you open a issue to resolve this inconsistency?

oddhack added a commit to KhronosGroup/Vulkan-Docs that referenced this issue Jan 13, 2019
  * Update release number to 98.

Public Issues:

  * Fix missing markup in flink:vkDestroyPipelineLayout valid usage
    statement (pull request 882).
  * Add missing contributors for `<<VK_EXT_buffer_device_address>>` (public
    pull request 891).

Internal Issues:

  * Detect nested bullet points in valid usage blocks and warn about them
    during VUID assignment (internal issue 1382).
  * Update the style guide to document the process for reserving new bits in
    bitmask types (internal issue 1411).
  * Clarify for slink:VkApplicationInfo::pname:apiVersion and in the
    <<fundamentals-validusage-versions, Valid Usage for Newer Core
    Versions>> section when it is valid for an application to use a certain
    version of Vulkan API functionality (for an instance and for a
    device/physical device); and when the validation layers must generate an
    error (internal issue 1412).
  * Add optional <<memory-model-availability-visibility, transitive
    availability/visibility operations to the memory model, including a new
    pname:vulkanMemoryModelAvailabilityVisibilityChains feature for
    slink:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR (internal issue
    1460).
  * Add the code:StorageBuffer storage class to those in the
    <<interfaces-resources-descset, Descriptor Set Interface>> (internal
    issue 1480).
  * Add missing `returnedonly` tags for a number of returned extension
    structures that can be passed in pname:pNext chains (internal issue
    1515).
  * Clean up and rearrange some spec language for
    slink:VkRenderPassCreateInfo and slink:VkAttachmentReference.txt
    (internal issue 1522).
  * Correctly round the code:OpVectorTimesScalar and
    code:OpMatrixTimesScalar SPIR-V operations in the <<Precision of core
    SPIR-V Instructions>> table (internal merge request 2996).
  * Work around cases in flink:vkCmdBeginTransformFeedbackEXT,
    flink:vkCmdEndTransformFeedbackEXT, and
    slink:VkPipelineCoverageModulationStateCreateInfoNV where an array
    parameter is `optional` but the length is not in `vk.xml`. This is an
    interim fix using `noautovalidity` + handcoded VU replacing those that
    should be autogenerated (internal issue 2944 and
    KhronosGroup/Vulkan-ValidationLayers#480).
  * Remove redundant capability validation of the code:float16 and code:int8
    SPIR-V capabilities from the <<spirvenv-capabilities, Capabilities>>
    section, since they are already covered in the preceding table.
  * Update check_spec_links script, including validation for reference page
    open blocks. Fix errors identified by the script.
@mikes-lunarg
Copy link
Contributor

Fixed by taking vk.xml updates in #721

@shannon-lunarg shannon-lunarg added this to the sdk-1.1.temp.0 milestone Feb 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants