mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-01-11 14:34:08 +00:00
9858c1e89e
* Update release number to 85.
Public Issues:
* Add self-dependency ename:VK_DEPENDENCY_BY_REGION_BIT valid usage
statements for slink:VkSubpassDependency(public pull request 778).
* Apply fix from pull request 742 to slink:VkSubpassDependency and
slink:VkSubpassDependency2 (public pull request 779).
* Specify the units of slink:VkBufferImageCopy::pname:bufferRowLength and
pname:bufferImageHeight as texels (public pull request 781).
* Better specify promoted parameter mapping in the
`<<VK_KHR_create_renderpass2>>` appendix (public pull request 782).
Internal Issues:
* Only include the <<fundamentals-validusage-versions, Valid Usage for
Newer Core Versions>> section in Vulkan 1.1 or later (internal issue
1381).
Other Issues:
* Clean up redundant valid usage language for the
`VK_ANDROID_external_memory_android_hardware_buffer` extension
interaction with slink:VkImageCreateInfo.
* Fix error in a flag name within valid usage statements for
slink:VkMemoryAllocateInfo.
* Clarify that memory types are not totally ordered in
slink:VkPhysicalDeviceMemoryProperties.
* For slink:VkWriteDescriptorSetInlineUniformBlockEXT, set
structextends="VkWriteDescriptorSet" in `vk.xml`, and make
slink:VkDescriptorSetLayoutBindingFlagsCreateInfoEXT::pname:pBindingFlags
optional.
* Add documentation of 'provisional' XML attribute to registry.txt.
New Extensions:
* `VK_NV_compute_shader_derivatives`
* `VK_NV_corner_sampled_image`
* `VK_NV_fragment_shader_barycentric`
* `VK_NV_mesh_shader`
* `VK_NV_representative_fragment_test`
* `VK_NV_scissor_exclusive`
* `VK_NV_shader_image_footprint`
* `VK_NV_shading_rate_image`
* `VK_NVX_raytracing`
114 lines
3.2 KiB
Plaintext
114 lines
3.2 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:VkImageCreateFlagBits
|
|
** ename:VK_IMAGE_CREATE_CORNER_SAMPLED_BIT_NV
|
|
|
|
=== New Enums
|
|
|
|
None.
|
|
|
|
=== New Structures
|
|
|
|
* elink: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
|