Bugs with proposed fixes for the core+KHR specification version 1.2.141

[naiveforce]

vkspec.pdf

Suggested fixes as comments placed throughout PDF build of KHR extended version 141 of the specification.

Comment primitives used and their intended meaning:

• red strike-trough: designates parts of the text that should be removed (may include single character sequences, punctuation marks as well as white spaces);
• green underline: designates parts of the text that should be replaced (see comment attached to each item for details)
• orange highlight: designates misc. editorial suggestions (see comment attached to each item for details)
• sticky note: designates parts of the text that might be missing (see comment attached to each item for details)

There are numerous VUs missing pNext description. I had being marking them, up to a point I came to a conclusion that it surely must be by design.

Most of the text in drawing-command-related VUs is duplicated across multiple variants of basic drawing/dispatching commands. Personally I found repeatedly reading same content over and over again distracting and tedious. Not to mention that it surely must be hard to maintain.

Consider using "comments view/list" or some sort of "go to next/previous comment" functionality of your PDF-viewer to not get overwhelmed or miss anything. Verified to view correctly in Adobe Acrobat Reader and built-in Firefox PDF-viewer.

Hope you will find it useful.

[krOoze]

Ok, 653 items; sounds like fun. I keep accumulator branch for these kind of little things myself; I am gonna see if I can merge some of your stuff in there (unless you intend to take this on yourself).

There are numerous VUs missing pNext description. I had being marking them, up to a point I came to a conclusion that it surely must be by design.

Yes, that is so (https://github.com/KhronosGroup/Vulkan-Docs/issues/1239).

[naiveforce]

By all means use it as you see fit. I've spent all of my mental stamina on repeatedly going through the spec and trying to catch as much as possible. Believe me adding these as comments to PDF was no fun either. By the time I've reached the final page it started to take up to several seconds just to create a new, empty comment.

[krOoze]

Hey, gotta enjoy all those AI-grade tasks while you still can. :p

[oddhack]

The repeated VUs are intentional as each of them turns into a separate validation path in the validation layers. They are not hard to maintain as they're only written once in the spec markup.

[oddhack]

As a general comment: while we appreciate good feedback, and while I'm sorry to tell you this given you've clearly put a lot of time into this, the practicalities of how we work as a group and how we process public feedback means there's no way we're going to engage on an issue with 653 different requests in finite time. You are more likely to get engagement if they are split and categorized by the functionality / part of the spec they apply to, and by the severity (typos are easy to fix, point fixes are tractable, suggested wholesale reorganizations of the document are exceedingly unlikely to get engagement by the Working Group).

Keep in mind that every single request that's made, aside from typos, requires it be brought up in a meeting, discussed, and have multiple eyes of already heavily committed WG members on it - and then a fix proposed and agreed on.