Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualMJP

Posted 06 February 2013 - 03:31 PM

HLSL essentially targets a virtual machine, where the supported instruction set of that VM is dictated by the shader model. When the shader gets compiled it outputs assembly using the instructions and registered that are supported by the shader model, and then when when you actually load the shader on the device the driver will JIT compile the assembly to the hardware-specific ISA of the GPU. This means there can (and will be) instructions that are supported by the hardware ISA but aren't supported by the shader model VM. So for instance Nvidia hardware might support an approximate sin/cos instruction in addition to the normal version, but since SM5.0 assembly only has normal sin/cos instructions HLSL can't expose it. For it to be exposed in HLSL, the approximate instruction would have to get added to the spec of a future shader model. However for this to happen, the instruction typically needs to be supported  by both Nvidia and AMD hardware. This has already happened several times in the past, for example SM5.0 added approximate reciprocal and reciprocal square root functions (rcp() and rsqrt()) as well as coarse-grained and fine-grained derivative functions. These instructions have existed for quite some time in GPU's, but until they were added to the SM5.0 spec they couldn't be directly targeted. Instead the driver might try decide when to use the approximate instructions when JIT compiling the shader.

As mhagain already explained, CUDA has the advantage of targeting a much more specific range of hardware. This means that Nvidia can expose the hardware more directly, which can give higher performance at the expense of tightly coupling your code with Nvidia hardware.


#1MJP

Posted 06 February 2013 - 03:28 PM

HLSL essentially targets a virtual machine, where the supported instruction set of that VM is dictated by the shader model. When the shader gets compiled it outputs assembly using the instructions and registered that are supported by the shader model, and then when when you actually load the shader on the device the driver will JIT compile the assembly to the hardware-specific ISA of the GPU. This means there can (and will be) instructions that are supported by the hardware ISA but aren't supported by the shader model VM. So for instance Nvidia hardware might support an approximate sin/cos instruction in addition to the normal version, but since SM5.0 assembly only has normal sin/cos instructions HLSL can't expose it. For it to be exposed in HLSL, the approximate instruction would have to get added to the spec of a future shader model. However for this to happen, the instruction typically needs to be supported  by both Nvidia and AMD hardware. This has already happened several times in the past, for example SM5.0 added approximate reciprocal and reciprocal square root functions (rcp() and rsqrt()) as well as coarse-grained and fine-grained derivative functions. These instructions have existed for quite some time in GPU's, but until they were added to the SM5.0 spec they couldn't be directly targeted. Instead the driver might try decide when to use the approximate instructions when JIT compiling the shader.


PARTNERS