mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-05 11:04:13 +00:00
e24e42dcff
* Update release number to 91.
Public Issues:
* Update Ubuntu subsystem build instructions in `BUILD.adoc` (public pull
request 624).
* Delete the `VK_KHR_mir_surface` extension from the Specification and
XML, due to EOL of the only driver known to have supported it, and
near-EOL of Mir itself (public issue 814).
* Fix options for some figures that were using old ones (public pull
request 841).
* Fix various accidentally repeated words (public pull request 843).
* Use `time.process_time()`, introduced in Python 3.3, in the scripts
instead of `time.clock()`, which will be removed in Python 3.8 (public
pull request 844).
Internal Issues:
* Update valid usage statements for
`VK_ANDROID_external_memory_android_hardware_buffer` in
slink:VkMemoryAllocateInfo,
slink:VkImportAndroidHardwareBufferInfoANDROID, and
flink:vkGetAndroidHardwareBufferPropertiesANDROID to actually be
verifiable (internal issue 1419).
* Update valid usage statements for
`VK_ANDROID_external_memory_android_hardware_buffer` in
slink:VkMemoryAllocateInfo, slink:VkImageCreateInfo, and
slink:VkImageViewCreateInfo to move valid usage statements in
doubly-nested bullet points up one level, accomodating limitations of
the valid usage extraction script that creates `validusage.json`
(internal issue 1434).
* Fix typo etext:VK_ACCESS_SHADING_RATE_IMAGE_BIT_NV to the correct
ename:VK_ACCESS_SHADING_RATE_IMAGE_READ_BIT_NV.
* Add missing etext:VK_STRUCTURE_TYPE_* tokens to appendices for
extensions missing them.
New Extensions:
* `VK_AMD_memory_overallocation_behavior`
* `VK_NV_ray_tracing`, replacing `VK_NVX_raytracing`
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
|
|
|
|
* 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
|