Bytecodewijzigingen in SM5.1
SM5.1 wijzigt hoe resourceregisters worden gedeclareerd en waarnaar wordt verwezen in instructies.
SM5.1 gaat verder met het declareren van een register 'variabele', vergelijkbaar met de manier waarop het wordt gedaan voor gedeelde groepsgeheugenregisters, geïllustreerd in het volgende voorbeeld:
Texture2D<float4> tex0 : register(t5, space0);
Texture2D<float4> tex1[][5][3] : register(t10, space0);
Texture2D<float4> tex2[8] : register(t0, space1);
SamplerState samp0 : register(s5, space0);
float4 main(float4 coord : COORD) : SV_TARGET
{
float4 r = coord;
r += tex0.Sample(samp0, r.xy);
r += tex2[r.x].Sample(samp0, r.xy);
r += tex1[r.x][r.y][r.z].Sample(samp0, r.xy);
return r;
}
De demontage van dit voorbeeld volgt:
// Resource Bindings:
//
// Name Type Format Dim Space Slot Elements
// ------------------------------ ---------- ------- ----------- ----- ---- ---------
// samp0 sampler NA NA 0 5 1
// tex0 texture float4 2d 0 5 1
// tex1[0][5][3] texture float4 2d 0 10 unbounded
// tex2[8] texture float4 2d 1 0 8
//
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// COORD 0 xyzw 0 NONE float xyzw
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_TARGET 0 xyzw 0 TARGET float xyzw
//
ps_5_1
dcl_globalFlags refactoringAllowed
dcl_sampler s0[5:5], mode_default, space=0
dcl_resource_texture2d (float,float,float,float) t0[5:5], space=0
dcl_resource_texture2d (float,float,float,float) t1[10:*], space=0
dcl_resource_texture2d (float,float,float,float) t2[0:7], space=1
dcl_input_ps linear v0.xyzw
dcl_output o0.xyzw
dcl_temps 2
sample r0.xyzw, v0.xyxx, t0[0].xyzw, s0[5]
add r0.xyzw, r0.xyzw, v0.xyzw
ftou r1.x, r0.x
sample r1.xyzw, r0.xyxx, t2[r1.x + 0].xyzw, s0[5]
add r0.xyzw, r0.xyzw, r1.xyzw
ftou r1.xyz, r0.zyxz
imul null, r1.yz, r1.zzyz, l(0, 15, 3, 0)
iadd r1.y, r1.z, r1.y
iadd r1.x, r1.x, r1.y
sample r1.xyzw, r0.xyxx, t1[r1.x + 10].xyzw, s0[5]
add o0.xyzw, r0.xyzw, r1.xyzw
ret
// Approximately 12 instruction slots used
Elk arceringsresourcebereik heeft nu een id (een naam) in de shader-bytecode. Tex1-patroonmatrix wordt bijvoorbeeld 't1' in de shader-bytecode. Als u unieke id's aan elk resourcebereik geeft, kunt u twee dingen doen:
- Identificeer ondubbelzinnig welk resourcebereik (zie dcl_resource_texture2d) wordt geïndexeerd in een instructie (zie voorbeeldinstructie).
- Voeg een set kenmerken toe aan de declaratie, bijvoorbeeld elementtype, onderdrukkingsgrootte, rasterbewerkingsmodus, enzovoort.
Houd er rekening mee dat de id van het bereik niet is gerelateerd aan de hlSL-ondergrensdeclaratie.
De volgorde van reflectieresourcebindingen en shaderdeclaratie-instructies is hetzelfde om de correspondentie tussen HLSL-variabelen en bytecode-id's te identificeren.
Elke instructie voor declaratie in SM5.1 gebruikt een 3D-operand om te definiëren: bereik-id, onder- en bovengrens. Er wordt een extra token verzonden om de registerruimte op te geven. Andere tokens kunnen ook worden verzonden om extra eigenschappen van het bereik over te brengen, bijvoorbeeld cbuffer of gestructureerde bufferdeclaratieinstructie, verzendt de grootte van de cbuffer of structuur. De exacte details van codering vindt u in d3d12TokenizedProgramFormat.h en D3D10ShaderBinary::CShaderCodeParser.
SM5.1-instructies verzenden geen aanvullende informatie over de bronoperand als onderdeel van de instructie (zoals in SM5.0). Deze informatie wordt nu verplaatst naar de instructies voor de declaratie. In SM5.0 moesten voor instructies voor het indexeren van resources resourcekenmerken worden beschreven in uitgebreide opcodetokens, omdat indexering de koppeling naar de declaratie verborgen heeft gemaakt. In SM5.1 wordt elke id (zoals 't1') ondubbelzinnig gekoppeld aan één declaratie die de vereiste resourcegegevens beschrijft. Daarom worden de uitgebreide opcodetokens die worden gebruikt voor instructies voor het beschrijven van resourcegegevens niet meer verzonden.
In niet-declaratie-instructies is een resourceoperand voor samplers, SRV's en UAV's een 2D-operand. De eerste index is een letterlijke constante die de bereik-id aangeeft. De tweede index vertegenwoordigt de lineaire waarde van de index. De waarde wordt berekend ten opzichte van het begin van de bijbehorende registerruimte (niet ten opzichte van het begin van het logische bereik) om beter te correleren met de basishandtekening en om de belasting van de stuurprogrammacompilator voor het aanpassen van de index te verminderen.
Een resourceoperand voor CBV's is een 3D-operand: letterlijke id van het bereik, index van de cbuffer, offset in het specifieke exemplaar van cbuffer.
Verwante onderwerpen