mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-25 12:35:11 +00:00
59750fe4c7
* Update release number to 121.
Github Issues:
* Add missing `structextends` attribute in `vk.xml` for
slink:VkPhysicalDevicePipelineExecutablePropertiesFeaturesKHR (public
issue 1018).
* Change attributes of flink:vkCmdCopyAccelerationStructureNV,
flink:vkCmdWriteAccelerationStructuresPropertiesNV,
flink:vkCmdBuildAccelerationStructureNV, and flink:vkCmdTraceRaysNV to
require that these commands execute outside renderpasses (public issue
1021).
* Add an issue to the `<<VK_EXT_buffer_device_address>>` appendix
discussing the introduction of new names and aliasing by equivalent old
names (public pull request 1024).
Internal Issues:
* Protect the `VK_KHR_sampler_mirror_clamp_to_edge` extension with
asciidoctor conditionals, and remove it from the core-only specification
builds, where it had previously been force-included in the Makefile. It
is now treated like any other extension (internal issue 1776).
* Edit some asciidoctor anchor names starting with `features-features-` to
just start with `features-`, since the old chapters was split into 3
pieces. There are still some mild naming inconsistencies with anchors
which may be addressed in the future (internal issue 1792).
* Add `KHR` alias for the non-suffixed extension token
ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE, for compatibility
with naming rules for extensions (internal issue 1796).
* Clarify requirements for external memory in NOTEs for
sname:VkExternalMemoryBufferCreateInfo, and valid usage statements for
flink:vkBindBufferMemory, slink:VkBindBufferMemoryInfo,
flink:vkBindImageMemory, and slink:VkBindImageMemoryInfo (internal merge
request 3301).
* Make extension version numbers in `vk.xml` and extension appendices
consistent. In a few cases, we could not recover history at this
granularity, and left the summary of a version's change undefined
(internal merge request 3323).
* Fix invocation of `CodeInlineMacro` in the Ruby extension backing the
`code:` macro, which was delegating to the wrong base class (internal
merge request 3331).
* Modify `reg.py` to do a better job of recognizing equivalent <enum>
definitions.
* Add a `sortorder` attribute to XML feature and extension tags.
New Extensions
* `<<VK_AMD_device_coherent_memory>>`
118 lines
3.4 KiB
Plaintext
118 lines
3.4 KiB
Plaintext
include::meta/VK_NV_corner_sampled_image.txt[]
|
|
|
|
*Last Modified Date*::
|
|
2018-08-13
|
|
*Contributors*::
|
|
- Jeff Bolz, NVIDIA
|
|
- Pat Brown, NVIDIA
|
|
- Chris Lentini, NVIDIA
|
|
|
|
This extension adds support for a new image organization, which this
|
|
extension refers to as "`corner-sampled`" images.
|
|
A corner-sampled image differs from a conventional image in the following
|
|
ways:
|
|
|
|
* Texels are centered on integer coordinates.
|
|
See <<textures-unnormalized-to-integer, Unnormalized Texel Coordinate
|
|
Operations>>
|
|
* Normalized coordinates are scaled using [eq]#coord * (dim - 1)# rather
|
|
than [eq]#coord * dim#, where dim is the size of one dimension of the
|
|
image.
|
|
See <<textures-normalized-to-unnormalized, normalized texel coordinate
|
|
transform>>.
|
|
* Partial derivatives are scaled using [eq]#coord * (dim - 1)# rather than
|
|
[eq]#coord * dim#.
|
|
See <<textures-scale-factor,Scale Factor Operation>>.
|
|
* Calculation of the next higher lod size goes according to
|
|
[eq]#{lceil}dim / 2{rceil}# rather than [eq]#{lfloor}dim / 2{rfloor}#.
|
|
See <<resources-image-miplevel-sizing,Image Miplevel Sizing>>.
|
|
* The minimum level size is 2x2 for 2D images and 2x2x2 for 3D images.
|
|
See <<resources-image-miplevel-sizing,Image Miplevel Sizing>>.
|
|
|
|
This image organization is designed to facilitate a system like Ptex with
|
|
separate textures for each face of a subdivision or polygon mesh.
|
|
Placing sample locations at pixel corners allows applications to maintain
|
|
continuity between adjacent patches by duplicating values along shared
|
|
edges.
|
|
Additionally, using the modified mipmapping logic along with texture
|
|
dimensions of the form [eq]#2^n^+1# allows continuity across shared edges
|
|
even if the adjacent patches use different level-of-detail values.
|
|
|
|
=== New Object Types
|
|
|
|
None.
|
|
|
|
=== New Enum Constants
|
|
|
|
* Extending elink:VkStructureType
|
|
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CORNER_SAMPLED_IMAGE_FEATURES_NV
|
|
* Extending elink:VkImageCreateFlagBits
|
|
** ename:VK_IMAGE_CREATE_CORNER_SAMPLED_BIT_NV
|
|
|
|
=== New Enums
|
|
|
|
None.
|
|
|
|
=== New Structures
|
|
|
|
* slink:VkPhysicalDeviceCornerSampledImageFeaturesNV
|
|
|
|
=== New Functions
|
|
|
|
None.
|
|
|
|
=== New Built-In Variables
|
|
|
|
None.
|
|
|
|
=== New SPIR-V Capabilities
|
|
|
|
None.
|
|
|
|
=== Issues
|
|
|
|
. What should this extension be named?
|
|
+
|
|
--
|
|
DISCUSSION: While naming this extension, we chose the most distinctive
|
|
aspect of the image organization and referred to such images as
|
|
"`corner-sampled images`".
|
|
As a result, we decided to name the extension NV_corner_sampled_image.
|
|
--
|
|
|
|
. Do we need a format feature flag so formats can advertise if they support corner-sampling?
|
|
+
|
|
--
|
|
DISCUSSION: Currently NVIDIA supports this for all 2D and 3D formats, but
|
|
not for cubemaps or depth-stencil formats.
|
|
A format feature might be useful if other vendors would only support this on
|
|
some formats.
|
|
--
|
|
|
|
. Do integer texel coordinates have a different range for corner-sampled images?
|
|
+
|
|
--
|
|
RESOLVED: No, these are unchanged.
|
|
--
|
|
|
|
. Do unnormalized sampler coordinates work with corner-sampled images? Are there any functional differences?
|
|
+
|
|
--
|
|
RESOLVED: Yes they work.
|
|
Unnormalized coordinates are treated as already scaled for corner-sample
|
|
usage.
|
|
--
|
|
|
|
. Should we have a diagram in the "`Image Operations`" chapter demonstrating different texel sampling locations?
|
|
+
|
|
--
|
|
UNRESOLVED: Probaby, but later.
|
|
--
|
|
|
|
=== Version History
|
|
|
|
* Revision 1, 2018-08-14 (Daniel Koch)
|
|
- Internal revisions
|
|
* Revision 2, 2018-08-14 (Daniel Koch)
|
|
- ???
|