mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-19 17:48:23 +00:00
279452463a
* Update release number to 92.
Public Issues:
* Move and modify valid usage statements dealing with pname:aspectMask in
flink:vkCmdClearColorImage, flink:vkCmdClearDepthStencilImage, and
slink:VkClearAttachment, so they are in places where all necessary
information is available (public issue 529).
* Fix math markup in <<textures-texel-anisotropic-filtering, Texel
Anisotropic Filtering>> (public pull request 840).
* Fix misspellings (public pull request 845).
Internal Issues:
* Add installation instructions and a Makefile "`chunked`" target for
chunked HTML generation (internal issue 1352).
* Fix pipeline mesh diagram style; also fix a minor bug in the classic
pipeline diagram where vertex/index buffers wrongly fed into the vertex
shader (internal issue 1436).
* Make asciidoctor ERROR output raise an error, and don't suppress
executed command output from CI make invocation (internal issue 1454).
* Minor typo fixes and clarifications for `VK_NV_raytracing`.
* Cleanup extension-specific properties
** Remove duplicated documentation for pname:maxDiscardRectangles,
pname:pointClippingBehavior, and pname:maxVertexAttribDivisor (they
shouldn't be documented with the other members of
slink:VkPhysicalDeviceLimits at all).
** Remove duplicate anchor for pname:maxVertexAttribDivisor
** Consistently document stext:VkPhysicalDevice<Extension>PropertiesKHR
*** Always document pname:sType/pname:pNext (was inconsistent before)
*** Always mention chaining to slink:VkPhysicalDeviceProperties2 (and not
as slink:VkPhysicalDeviceProperties2KHR)
*** Always include Valid Usage statements last
* Update Makefile 'checklinks' target and associated scripts, and fix
markup problems identified by checkLinks.py, so that we can rely on the
checklinks script as part of Gitlab CI.
116 lines
3.3 KiB
Plaintext
116 lines
3.3 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
|