35
edits
Changes
Jump to navigation
Jump to search
mLine 1:
Line 1: − + − + Line 29:
Line 29: − + Line 45:
Line 45: − + Line 57:
Line 57: − + − + + + + + + + + + + + + + Line 80:
Line 92: + + + + + + + + Line 92:
Line 112: + + + + + + + + + + + + + + + + + + + + + + + + Line 143:
Line 187: − + + + + + Line 152:
Line 200: − + Line 162:
Line 210: − + Line 176:
Line 224: − + Line 193:
Line 241: − + Line 212:
Line 260: − + Line 243:
Line 291: − + Line 265:
Line 313: − + + − + + − + + − + + + + + + + Line 281:
Line 338: − + Line 313:
Line 370: + + + + + Line 325:
Line 387: − + − + Line 354:
Line 416: − + Line 488:
Line 550: − + Line 496:
Line 558: − +
no edit summary
[[Category:File formats]]
[[Category:File formats]]
The SHBIN (SHader BINary) file is used to contain compiled and linked shader programs. These can include vertex shaders (typically compiled from .vsh files) and geometry shaders (typically compiled from .gsh files, though .asm have been observed). In commercial applications, SHBIN files can be found as standalone files with the extension .shbin, or contained within .bcsdr files. BCSDR files use CGFX as a container, but the underlying DVLB/DVLP/DVLE structure remains unchanged.
The SHBIN (SHader BINary) format is used to contain compiled and linked shader programs. These can include vertex shaders and geometry shaders. In commercial applications, SHBIN files can be found as standalone files with the extension .shbin, or within container formats like, for example, [[CGFX]] (with the extension .bcsdr). They are typically compiled from .vsh files, .gsh files, and sometimes .asm files.
A SHBIN's structure starts with a generic header (DVLB), then a single program header (DVLP), then DVLE(s). The program header specifies the generic parts of the shader, i.e. the shader program data, the operand descriptor data, and a filename symbol table. The contextual details (entry point, constant values, debug symbols, etc) are specified in an executable header (DVLE). There may be multiple DVLE headers, so in this sense multiple shaders sharing the same program code can be stored in a single SHBIN. Hence for the following note the distinction between "program" and "executable".
A SHBIN's structure starts with a binary header (DVLB), then a single program header (DVLP), then one or more executable headers DVLE(s). The binary header specifies the number and location of DVLEs. The program header specifies the generic parts of the shader (i.e. the shader program data, the operand descriptor data, and a filename symbol table). The executable headers specify the contextual details (i.e. entry point, constant values, debug symbols, etc). There may be multiple executable headers, so in this sense multiple shaders sharing the same program code can be stored in a single SHBIN. Hence for the following, note the distinction between "program" and "executable".
For a description of the instruction set, see the following page : [[Shader Instruction Set]]
For a description of the instruction set, see the following page : [[Shader Instruction Set]]
|}
|}
The DVLP file comes directly after the header.
The DVLP section comes directly after the binary header.
== DVLP ==
== DVLP ==
| 0x4
| 0x4
| 0x4
| 0x4
| ? (Maybe a version number?)
| Unknown, same value as in DVLE. (Likely a version number)
|-
|-
| 0x8
| 0x8
| 0x10
| 0x10
| 0x4
| 0x4
| Offset (relative to DVLP start) to shader instruction extension table
| Offset (relative to DVLP start) to operand descriptor table
|-
|-
| 0x14
| 0x14
| 0x4
| 0x4
| Number of shader instruction extension table entries (each entry is 8-byte long)
| Number of operand descriptor table entries (each entry is 8-bytes long)
|-
|-
| 0x18
| 0x18
| 0x4
| Unknown (Same value as offset to filename symbol table?)
|-
| 0x1C
| 0x4
| Unknown (Always zero?)
|-
| 0x20
| 0x4
| 0x4
| Offset (relative to DVLP start) to filename symbol table
| Offset (relative to DVLP start) to filename symbol table
|-
| 0x24
| 0x4
| Size of filename symbol table
|-
|-
|}
|}
| 0x4
| 0x4
| Magic "DVLE"
| Magic "DVLE"
|-
| 0x4
| 0x2
| Unknown, same value as in DVLP. (Likely a version number)
|-
|-
| 0x6
| 0x6
| 0x1
| 0x1
| Shader type (0x0 = vertex shader, 0x1 = geometry shader; might contain other flags)
| Shader type (0x0 = vertex shader, 0x1 = geometry shader; might contain other flags)
|-
| 0x7
| 0x1
| true = merge vertex and geometry shader outmaps (geometry shader)
|-
|-
| 0x8
| 0x8
| 0x4
| 0x4
| Executable's program's endmain offset in binary blob (in words)
| Executable's program's endmain offset in binary blob (in words)
|-
| 0x10
| 0x2
| Bitmask of used input registers
|-
| 0x12
| 0x2
| Bitmask of used output registers
|-
| 0x14
| 0x1
| Geometry shader type (point = 0x0, variable/subdivide = 0x1, fixed/particle = 0x2)
|-
| 0x15
| 0x1
| Starting float constant register number for storing the fixed-size primitive vertex array (geometry shader, fixed mode)
|-
| 0x16
| 0x1
| Number of fully-defined vertices in the variable-size primitive vertex array (geometry shader, variable mode)
|-
| 0x17
| 0x1
| Number of vertices in the fixed-size primitive vertex array (geometry shader, fixed mode)
|-
|-
| 0x18
| 0x18
|-
|-
| 0x0
| 0x0
| 0x1
| 0x2
| Label ID
| Label ID
|-
| 0x0
| 0x2
| Unknown (always 1?)
|-
|-
| 0x4
| 0x4
| 0x8
| 0x8
| 0x4
| 0x4
| ?
| Size of label's location (in words). 0xFFFFFFFF/(uint32_t)-1 if there is no size.
|-
|-
| 0xC
| 0xC
=== Constant Table Entry ===
=== Constant Table Entry ===
Each executable's constants are stored as in constant uniform table. This information is used by ctrulib's SHDR framework to automatically send those values to the GPU when changing to a given program. An entry is constituted by a header and the constant data, the latter of which uses a format specific to the constant type.
Each executable's constants are stored in a constant table. This information is used by ctrulib's SHDR framework to automatically send those values to the GPU when changing to a given program. An entry is constituted by a header and the constant data, the latter of which uses a format specific to the constant type.
{| class="wikitable" border="1"
{| class="wikitable" border="1"
| 0x2
| 0x2
| 0x1
| 0x1
| Uniform ID
| Constant register ID
|}
|}
| 0x2
| 0x2
| 0x1
| 0x1
| Uniform bool ID
| Boolean constant register ID
|-
|-
| 0x4
| 0x4
| 0x2
| 0x2
| 0x1
| 0x1
| Uniform integer vector ID
| Integer constant register ID
|-
|-
| 0x4
| 0x4
| 0x2
| 0x2
| 0x1
| 0x1
| Uniform vector ID
| floating-point constant register ID
|-
|-
| 0x4
| 0x4
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
! Bit
! Offset
! Size
! Description
! Description
|-
|-
| 0-3
| 0x0
| 0x2
| Output type (see table below)
| Output type (see table below)
|-
|-
| 16-19
| 0x2
| 0x2
| Register ID
| Register ID
|-
|-
| 32-35
| 0x4
| 0x2
| Output attribute component mask (e.g. 5=xz)
| Output attribute component mask (e.g. 5=xz)
|-
| 0x6
| 0x2
| Unknown (Consistently the same number throughout the DVLE, may vary between DVLEs?)
|-
|}
|}
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
! ID
! Type
! Description
! Description
|-
|-
=== Uniform Table Entry ===
=== Uniform Table Entry ===
Keep in mind that the usage of the term "Uniform" here is used as [https://developer.download.nvidia.com/CgTutorial/cg_tutorial_chapter03.html defined by Nvidia] (variable who obtains its initial value from an external environment) and not as defined by RenderMan/GLSL (variables whose values are constant over a shaded surface).
The uniform table contains a list of all registers whose initial values are derived by an external source along with their layout and associated symbol.
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
| 0x4
| 0x4
| 0x2
| 0x2
| Variable start register
| Register index of the start of the uniform
|-
|-
| 0x6
| 0x6
| 0x2
| 0x2
| Variable end register (equal to start register for non-arrays)
| Register index of the end of the uniform (equal to start register for non-arrays)
|-
|-
|}
|}
== DVOJ ==
== DVOJ ==
There is another file format for shaders which starts with the string "DVOJ". This format seems to be used for unlinked shader objects. It seems likely that one or multiple DVOJs can be linked to a DVLB file, similarly to the C compilation model.
There is another file format for shaders, which starts with the string "DVOJ". This format seems to be used for unlinked shader objects. It seems likely that one or multiple DVOJs can be linked to a DVLB file, similarly to the C compilation model.
Structurally, a DVOJ header captures all information there is about a single shader instance. It uses the same fields like the DVLB, DVLP, and DVLE structures, but also stores two unknown blocks of data. It seems that the entry point of a DVOJ is always the first shader instruction.
Structurally, a DVOJ header captures all information there is about a single shader instance. It uses the same fields like the DVLB, DVLP, and DVLE structures, but also stores two unknown blocks of data. It seems that the entry point of a DVOJ is always the first shader instruction.
| 0x0
| 0x0
| 0x4
| 0x4
|
| This seems to be an index of a shader instruction. All non-nullary instructions seem to be referenced exactly once.
|-
|-
| 0x4
| 0x4
| 0x8
| 0x8
| 0x4
| 0x4
| This seems to be an index of some sort.
|
|-
|-
|}
|}