Any way to sampler2DShadow from DX9-style HLSL?

[StarsX]

It seems good with our Vulkan + HLSL using DX11-style SamplerComparisonState with the latest Vulkan SDK. However, it seems OpenGL only supports combined image sampler (such as sampler2DShadow) in shaders, so OpenGL + HLSL needs DX9 style, but standard Shader Model 3 has no comparison sampler for hardware percentage closer filter (PCF). I wonder if we need something like [[spv::sampler_shadow]] to identify a Sampler2D as a shadow sampler. Or any other way? Thanks.

[greg-lunarg]

My current charter does not allow me to design or implement this. If someone wishes to design and implement this, I would be open to integrating it.

[StarsX]

My current charter does not allow me to design or implement this. If someone wishes to design and implement this, I would be open to integrating it.

Thanks a lot for your reply. Firstly, I just want to confirm if what I said above is indeed a missing feature. Then, may I have your help to evaluate and determine a sketchy solution?

[greg-lunarg]

Yes, I believe that it is a missing feature. I also believe that support for it could be added to glslang consistently. I would be happy to evaluate any proposals.

[greg-lunarg]

For my own notes, I would just like to clarify that what you are wishing to do is use an HLSL shader with OpenGL API. As such the shader must be DX9-style / Shader Model 3 because texture/sampler must be combined for OGL. Unfortunately, Shader Model 3 does not support the shadow sampling you want. So we must figure out a way to add this.

Looking at this a little closer, while I don't see a theoretical not to add this, I am not so sure about the ease with which we could practically add this.

The problem I see with the [[...]] notation is that it doesn't look like it can be used to create the builtin sample functions we will need to specify the depth comparison reference value.

It seems it would be easiest to just expand the DX9 supported HLSL to include these new types and builtins as first-class, but there may be practical reasons not to do this.

@johnkslang Is there precedence for extending HLSL in glslang for something like this? Are there very good reasons NOT to extend HLSL in glslang? One problem I can see is that we would have to start a spec for "non-standard" HLSL we support. Can you see any other good way to do this?

[greg-lunarg]

To be clear, I would propose doing this extending under a new glslangValidator command line option: --hlsl-dx9-extended.

[StarsX]

Yes, I believe that it is a missing feature. I also believe that support for it could be added to glslang consistently. I would be happy to evaluate any proposals.

Thank you. Some additional information: standard DX9 has no hardware Percentage-Closer Filtering (PCF, equivalent to comparison sampler state in DX10/11/12), but GPU vendors have provided the extensions. Creating a DX9 texture with D3DFMT_D16/D3DFMT_D24X8/D3DFMT_D24S8, then PCF will be applied on all texture fetches from a depth stencil texture. Practically, tex2D only takes float2 UV parameters, so it is impossible to pass a z value for comparison. Thus, tex2Dproj is commonly used, which takes float4 UV parameters and the z component is just a placeholder in standard DX9 HLSL.

Unfortunately, an OpenGL driver cannot do something like this (implicitly regarding OpImageSampleXXX as OpImageSampleDrefXXX according to the texture format). Otherwise, it would violate OpenGL spec., since OpenGL GLSL already has sampler2DShadow. That's why I think the most feasible solution seems on HLSL side instead of OpenGL API side.

DX9 PCF references: https://developer.amd.com/wordpress/media/2012/10/Advanced-DX9-Capabilities-for-ATI-Radeon-Cards_v2.pdf https://developer.download.nvidia.cn/assets/gamedev/docs/shadow_mapping.pdf

[greg-lunarg]

If a sampler is tagged with [[spv::shadow]] and is passed to tex2Dproj I would imagine logic could be added to the compiler to generate OpImageSampleDrefImplicitLod instead. This could probably be done without creating a special "hlsl-dx9-extended" command line option to allow it.

Of course, such a mechanism is a little confusing and unintuitive and my preference would be to create new intuitive names under a new "hlsl-dx9-extended" command line option. But, if you would prefer overloading tex2Dproj for some level of compatibility with other such DX9 shaders, I would be open to that.

[StarsX]

If a sampler is tagged with [[spv::shadow]] and is passed to tex2Dproj I would imagine logic could be added to the compiler to generate OpImageSampleDrefImplicitLod instead. This could probably be done without creating a special "hlsl-dx9-extended" command line option to allow it.

Of course, such a mechanism is a little confusing and unintuitive and my preference would be to create new intuitive names under a new "hlsl-dx9-extended" command line option. But, if you would prefer overloading tex2Dproj for some level of compatibility with other such DX9 shaders, I would be open to that.

Thank you. But I have no idea about which is better. I can only provide what the GPU vendors did on DX9 as a reference. tex2Dproj, tex2Dlod and tex2Dbias can all be PCF, as their texcoord argument is float4. But tex2D and tex2Dgrad cannot, because their texcoord arg is float2. https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-tex2dlod https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-tex2dproj https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-tex3dbias

Finally, I'll follow your determined solution.

[greg-lunarg]

I just remembered that the most recent version of glslang now disallows -D -G, even with --hlsl-dx9-compatible (PR #2497). This is because we want to make sure the capability is well thought out and implemented before we advertise it as available. The general request for this capability is documented in #1417. Enabling this is possibly not that much work, but as I mentioned earlier, I am currently not funded to enable this, although am available to help integrate it.

I will leave this issue open since it is requesting capability over and above #1417, but I thought you should be aware of all this.

[rdb]

The way I've worked around this is define a preamble that defines new DX9-like sampler2DShadow and shadow2D functions that under the hood actually use DX10-style types, like so:

typedef Texture1D sampler1DShadow;
typedef Texture2D sampler2DShadow;
typedef TextureCube samplerCubeShadow;

SamplerComparisonState __builtin_shadow_sampler;

float4 shadow1D(sampler1DShadow samp, float3 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.x, s.z);
}

float4 shadow1DProj(sampler1DShadow samp, float4 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.x / s.w, s.z / s.w);
}

float4 shadow2D(sampler2DShadow samp, float3 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.xy, s.z);
}

float4 shadow2DProj(sampler2DShadow samp, float4 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.xy / s.w, s.z / s.w);
}

float4 shadowCube(samplerCubeShadow samp, float4 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.xyz, s.w);
}

You could even overload tex2D to take additional arguments this way.

[StarsX]

The way I've worked around this is define a preamble that defines new DX9-like sampler2DShadow and shadow2D functions that under the hood actually use DX10-style types, like so:

typedef Texture1D sampler1DShadow;
typedef Texture2D sampler2DShadow;
typedef TextureCube samplerCubeShadow;

SamplerComparisonState __builtin_shadow_sampler;

float4 shadow1D(sampler1DShadow samp, float3 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.x, s.z);
}

float4 shadow1DProj(sampler1DShadow samp, float4 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.x / s.w, s.z / s.w);
}

float4 shadow2D(sampler2DShadow samp, float3 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.xy, s.z);
}

float4 shadow2DProj(sampler2DShadow samp, float4 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.xy / s.w, s.z / s.w);
}

float4 shadowCube(samplerCubeShadow samp, float4 s) {
  return samp.SampleCmp(__builtin_shadow_sampler, s.xyz, s.w);
}

You could even overload tex2D to take additional arguments this way.

Thank you. I’ll try this way first.

[StarsX]

Any update? Redeclare the initial user requirement: Any way to combined shadow image-sampler in HLSL like DX9 style, which can be used for OpenGL.

Thanks.

[StarsX]

Any solution plan on this? Or is it possible to auto convert DX11-style Sample() with the separate texture and sampler to combined image-sampler SPIR-V op when in OpenGL mode?

Thanks.

[StarsX]

In Microsoft DXC, they proposed [[vk::combinedImageSampler]] to make DX11-style Sample() being combined image-sampling. https://github.com/microsoft/DirectXShaderCompiler/wiki/Vulkan-combined-image-sampler-type

Does glslang support it for OpenGL?

[StarsX]

In Microsoft DXC, they proposed [[vk::combinedImageSampler]] to make DX11-style Sample() being combined image-sampling. https://github.com/microsoft/DirectXShaderCompiler/wiki/Vulkan-combined-image-sampler-type

Does glslang support it for OpenGL?

Any update?

[greg-lunarg]

I am not finding support for [[vk::combinedImageSampler]] in glslang.

As for the larger question, my status has not changed from my entry above and I am not aware of any current effort to implement this.

[StarsX]

I am not finding support for [[vk::combinedImageSampler]] in glslang.

As for the larger question, my status has not changed from my entry above and I am not aware of any current effort to implement this.

Hoping it could be added.

[StarsX]

I am not finding support for [[vk::combinedImageSampler]] in glslang.

As for the larger question, my status has not changed from my entry above and I am not aware of any current effort to implement this.

Is there any intention for this feature? 🥺 Then, HLSL compiled by glslang could cover almost all standard functionalities for OpenGL 4.6.

[greg-lunarg]

Is there any intention for this feature?

I am not aware of one at this time.