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
|