@@ -252,7 +252,7 @@ more than one shader_record_nv block statically used per shader entry point
252
252
otherwise results are undefined."
253
253
254
254
The official Khronos ray tracing extension also comes with a SPIR-V storage class
255
- that has the same functionality. The ``[[vk::shader_record_ext]] `` annotation can
255
+ that has the same functionality. The ``[[vk::shader_record_ext]] `` annotation can
256
256
be used when targeting the SPV_KHR_ray_tracing extension.
257
257
258
258
Builtin variables
@@ -1279,6 +1279,39 @@ will be translated into
1279
1279
%myBuffer1 = OpVariable %_ptr_Uniform_type_ByteAddressBuffer Uniform
1280
1280
%myBuffer2 = OpVariable %_ptr_Uniform_type_RWByteAddressBuffer Uniform
1281
1281
1282
+ Rasterizer Ordered Views
1283
+ ------------------------
1284
+
1285
+ The following types are rasterizer ordered views:
1286
+
1287
+ * ``RasterizerOrderedBuffer ``
1288
+ * ``RasterizerOrderedByteAddressBuffer ``
1289
+ * ``RasterizerOrderedStructuredBuffer ``
1290
+ * ``RasterizerOrderedTexture1D ``
1291
+ * ``RasterizerOrderedTexture1DArray ``
1292
+ * ``RasterizerOrderedTexture2D ``
1293
+ * ``RasterizerOrderedTexture2DArray ``
1294
+ * ``RasterizerOrderedTexture3D ``
1295
+
1296
+ These are translated to the same types as their equivalent RW* types - for
1297
+ example, a ``RasterizerOrderedBuffer `` is translated to the same SPIR-V type as
1298
+ an ``RWBuffer ``. The sole difference lies in how loads and stores to these
1299
+ values are treated.
1300
+
1301
+ The access order guarantee made by ROVs is implemented in SPIR-V using the
1302
+ `SPV_EXT_fragment_shader_interlock <https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/EXT/SPV_EXT_fragment_shader_interlock.asciidoc >`_.
1303
+ When you load or store a value from or to a rasterizer ordered view, using
1304
+ either the ``Load*() `` or ``Store*() `` methods or the indexing operator,
1305
+ ``OpBeginInvocationInterlockEXT `` will be inserted before the first access and
1306
+ ``OpEndInvocationInterlockEXT `` will be inserted after the last access.
1307
+
1308
+ An execution mode will be added to the entry point, depending on the sample
1309
+ frequency, which will be deduced based on the semantics inputted by the entry
1310
+ point. ``PixelInterlockOrderedEXT `` will be selected by default,
1311
+ ``SampleInterlockOrderedEXT `` will be selected if the ``SV_SampleIndex ``
1312
+ semantic is input, and ``ShadingRateInterlockOrderedEXT `` will be selected if
1313
+ the ``SV_ShadingRate `` semantic is input.
1314
+
1282
1315
HLSL Variables and Resources
1283
1316
============================
1284
1317
@@ -3858,14 +3891,14 @@ implicit ``vk`` namepsace.
3858
3891
3859
3892
// Implicitly defined when compiling to SPIR-V.
3860
3893
namespace vk {
3861
-
3894
+
3862
3895
const uint CrossDeviceScope = 0;
3863
3896
const uint DeviceScope = 1;
3864
3897
const uint WorkgroupScope = 2;
3865
3898
const uint SubgroupScope = 3;
3866
3899
const uint InvocationScope = 4;
3867
3900
const uint QueueFamilyScope = 5;
3868
-
3901
+
3869
3902
uint64_t ReadClock(in uint scope);
3870
3903
T RawBufferLoad<T = uint>(in uint64_t deviceAddress,
3871
3904
in uint alignment = 4);
@@ -3918,20 +3951,20 @@ functionality to HLSL:
3918
3951
3919
3952
.. code :: hlsl
3920
3953
3921
- // RawBufferLoad and RawBufferStore use 'uint' for the default template argument.
3954
+ // RawBufferLoad and RawBufferStore use 'uint' for the default template argument.
3922
3955
// The default alignment is 4. Note that 'alignment' must be a constant integer.
3923
3956
T RawBufferLoad<T = uint>(in uint64_t deviceAddress, in uint alignment = 4);
3924
3957
void RawBufferStore<T = uint>(in uint64_t deviceAddress, in T value, in uint alignment = 4);
3925
3958
3926
3959
3927
- These intrinsics allow the shader program to load and store a single value with type T (int, float2, struct, etc...)
3960
+ These intrinsics allow the shader program to load and store a single value with type T (int, float2, struct, etc...)
3928
3961
from GPU accessible memory at given address, similar to ``ByteAddressBuffer.Load() ``.
3929
- Additionally, these intrinsics allow users to set the memory alignment for the underlying data.
3930
- We assume a 'uint' type when the template argument is missing, and we use a value of '4' for the default alignment.
3962
+ Additionally, these intrinsics allow users to set the memory alignment for the underlying data.
3963
+ We assume a 'uint' type when the template argument is missing, and we use a value of '4' for the default alignment.
3931
3964
Note that the alignment argument must be a constant integer if it is given.
3932
3965
3933
- Though we do support setting the `alignment ` of the data load and store, we do not currently
3934
- support setting the memory layout for the data. Since these intrinsics are supposed to load
3966
+ Though we do support setting the `alignment ` of the data load and store, we do not currently
3967
+ support setting the memory layout for the data. Since these intrinsics are supposed to load
3935
3968
"arbitrary" data to or from a random device address, we assume that the program loads/stores some "bytes of data",
3936
3969
but that its format or layout is unknown. Therefore, keep in mind that these intrinsics
3937
3970
load or store ``sizeof(T) `` bytes of data, and that loading/storing data with a struct
0 commit comments