Alterações de código de bytes no SM5.1
O SM5.1 altera a forma como os registros de recursos são declarados e referenciados nas instruções.
O SM5.1 se move para declarar uma "variável" de registro, semelhante à forma como ela é feita para registros de memória compartilhada em grupo, ilustrado pelo exemplo a seguir:
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;
}
A desmontagem deste exemplo segue:
// 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
Cada intervalo de recursos do sombreador agora tem uma ID (um nome) no código de bytes do sombreador. Por exemplo, a matriz de textura tex1 se torna 't1' no código de bytes do sombreador. Fornecer IDs exclusivas para cada intervalo de recursos permite duas coisas:
- Identifique sem ambiguidade qual intervalo de recursos (consulte dcl_resource_texture2d) está sendo indexado em uma instrução (consulte a instrução de exemplo).
- Anexe o conjunto de atributos à declaração, por exemplo, tipo de elemento, tamanho do passo, modo de operação de varredura etc..
Observe que a ID do intervalo não está relacionada à declaração de limite inferior HLSL.
A ordem das associações de recursos de reflexão e instruções de declaração de sombreador é a mesma para ajudar a identificar a correspondência entre variáveis HLSL e IDs de código de bytes.
Cada instrução de declaração no SM5.1 usa um operando 3D para definir: ID do intervalo, limites inferior e superior. Um token adicional é emitido para especificar o espaço de registro. Outros tokens também podem ser emitidos para transmitir propriedades adicionais do intervalo, por exemplo, cbuffer ou instrução de declaração de buffer estruturado emite o tamanho do cbuffer ou da estrutura. Os detalhes exatos da codificação podem ser encontrados em d3d12TokenizedProgramFormat.h e D3D10ShaderBinary::CShaderCodeParser.
As instruções do SM5.1 não emitirão informações adicionais de operando de recurso como parte da instrução (como no SM5.0). Essas informações agora são movidas para as instruções de declaração. No SM5.0, as instruções de indexação de recursos exigiam que os atributos de recurso fossem descritos em tokens opcode estendidos, já que a indexação ofuscava a associação à declaração. No SM5.1, cada ID (como 't1') está inequívocamente associada a uma única declaração que descreve as informações de recurso necessárias. Portanto, os tokens opcode estendidos usados nas instruções para descrever informações de recurso não são mais emitidos.
Em instruções de não declaração, um operando de recurso para samplers, SRVs e UAVs é um operando 2D. O primeiro índice é uma constante literal que especifica a ID do intervalo. O segundo índice representa o valor linearizado do índice. O valor é calculado em relação ao início do espaço de registro correspondente (não relativo ao início do intervalo lógico) para correlacionar melhor com a assinatura raiz e reduzir a carga do compilador do driver de ajustar o índice.
Um operando de recurso para CBVs é um operando 3D: ID literal do intervalo, índice do cbuffer, deslocado para a instância específica de cbuffer.
Tópicos relacionados