-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complete HLSL -> SPIR-V translator #362
Comments
The "misc pending intrinsics" line above includes both the "unusual" intrinsics like printf as well as ones that accept either 1-vectors or Nx1 mats, which can be added, but aren't yet available. |
also would be nice if you can add DX12 HLSL support.. parsing RootSignature,etc.. [RootSignature(PostEffects_RootSig)] |
|
The only things missing there now are arguably orthogonal features such as |
(Edit for strikethrough now that this is in the main list) |
I think this can be marked as done, modulo a few things with no feature mappings:
DX9 texturing is still a TODO. |
RWTextures/Buffers is |
One of the most exciting feature of hlsl against glsl is ability to write several entry points in one file. And SPIR-V support this feature too. But right now you need to explicitly set only one entry point. I've implemented function addEntryPoint(std::string name, EShLanguage stage) but I've gotten multiple issues with semantic parsing. It's tricky to workaround all cases. Do you plan to support multiple entrypoints? |
This has come up in a couple places. First, an HLSL file with multiple entry points is really only valid to parse a single entry point at a time, because of the semantic changes. Second, there should be an independent modular tool for taking two SPIR-V modules and merging them into a single module. Combined, these two points indicates the correct design is to independently compile a source file, once for each entry point, making a set of SPIR-V modules, and then use a SPIR-V merging tool to merge multiple modules into a single module. |
I don't understand where ambiguity comes from. Can you give me example? For instance, I use shaders like this:
|
If you compiled this three times, once for each entry point, and got three SPIR-V modules, which could potentially then be merged together, would that work? The problems comes in if one potential entry point calls another, which is supported and happens:
The semantics of I/O for |
Yeah, it works. But it increase compilation time x3. Moreover, it require additional tool (is it exist?). Situation mentioned by you is unable to compile with several entrypoints, right. And it's ok to produce invalid code in this situation. But it is rare case. Why not to support multiply entrypoints when it is possible? |
Small feature request: Support
to default to row major matrices. Right now the pragma seems to be without effect. |
Two more questions: Are geometry shaders supported? I can't seem to get them to parse. #590 Additionally, is there any way to declare textures in HLSL to get combined texture/sampler objects in the SPIR-V? I need those for later spirv-cross SPIR-V->GLSL code generation, it seems... |
Texture2D g_texture : register(t0); This works well. Both in spir-v, and in glsl (I use spirv-cross). |
Yeah, oops - I got it working too right after posting, I just forgot to call build_combined_image_samplers in spirv-cross. Though, that still creates separated sampler/texture in SPIR-V which is not optimal in Vulkan... Also need to look into how the numbering will work for that. |
Not yet, but seems like a good thing for the list above, along with DS/HS. There is some CS support (e.g, numthreads). |
BTW, this item:
Can be marked as done (in #570). |
It seems like I made multiple entypoint processing. Strategy:
|
About that one: there are Nx1 and 1xN mats now, and associated intrinsic overloads accepting mats. Printf is still not available though, nor noise, msad4, errorf, and maybe a few others. |
Can probably mark as implemented, and defects can be logged if and when they appear. |
Can be marked as done. |
Hi! I found that texture intrinsic functions are not working when having a texture object with just one component. Example (based on altering the hlsl.getdimensions.dx10.frag in the test folder):
fails with something like
I did some digging and the issue seems to be that the intrinsic table does not have the function signetures required for scalar textures (aka shadow/depth textures). In other words: the table provides something like Cheers, P.S.: Same is true for .Load etc. |
Hi @ClemensRoegner, Could you submit an issue for this with a compilable example (so we can discuss under its own thread)? I tried the code below which compiles cleanly for me in current master (136b1e2). Once I have the magic sauce to duplicate it, I'll have a look and see what's going wrong. It looks like there is a hole in the current test coverage around texture intrinsics with sub-vec4 templatized texture types, so maybe something has fallen through the cracks... thanks!
|
Yeah, sorry I checked the glslang version again and it seems like the old one (distributed with the vulkan sdk) still has the problem. Not the current one. Terrible sorry for the fuzz. |
@ClemensRoegner - ok, glad it's OK now! |
Will support of conversion HLSL shader model 6.0 to SPIRV with extensions? |
The line item text above sounds like it's talking about returning structures from texture fetch, ala "Texture2D <mystruct_t> foo;", but #569 was talking about StructuredBuffer<mystruct_t>. I've been thinking of those as independent features with little shared implementation. Maybe there should be two line items? I think StructuredBuffers with user struct types is already implemented, but textures of user structs are not. (They support vectors and scalars of basic types as template parameters so far, but HLSL also allows templatizing on user structs whose members must be of the same basic type, with any mix of vectorness up to 4 total components). I think it can be added in a lightweight way without having to jam a whole type object into a TSampler. I could take a swing at that. It's probably just down to luck that no workload has wanted it yet. Edit: in progress as |
Looks like microsoft is also doing a hlsl->spir-V compiler using their open source hlsl compiler: https://github.com/Microsoft/DirectXShaderCompiler/blob/master/docs/SPIR-V.rst |
Can someone clarify if there will be any relationship/collaboration between DirectXShaderCompiler and Khronos to make HLSL first citizen in Vulkan? From the outside it seems there's a race between the two projects, that also have incompatible approaches in some aspects. I've also the feeling, but this is just my opinion, that glslang will always struggle behind with regard to feature parity with HLSL, carrying potentially more bugs than the counterpart and also risks of regressions in glsl because of the clutter necessary to support substantially different languages. Also another question: with the announce in Vulkan 1.1 of the support for HLSL do Khronos specifically refers to the implementation in glslang or they leave it open to other implementations too? |
The only language that is really first class in Vulkan is SPIR-V. SPIR-V is made to support lots of high-level language projects, like glslang GLSL, glslang HLSL, the DXC-based SPIR-V back end, etc. Khronos-level extension support for HLSL is for HLSL in general, across multiple potential front ends.
Both projects are underway, following their natural evolution, with different strengths/weaknesses, levels of contributions, etc. Neither will see support cut off. Contributions will always be accepted, pending review, etc.
These would be nice to converge, where they exist and can be converged, and have resources to converge them. Specific issues will help.
Yes, that's probably true, for new features that show up first in MS front-ends.
Actually, there is very little risk of bugs to GLSL due to HLSL support. There really is not an issue here.
Khronos does not pick a favored HLSL front end. Other HLSL front ends are welcome to participate, and have different strengths/weaknesses. |
Also, from #1346: "Support 64-bit integers" (part of SM6). |
The SM6 wave stuff was added. |
Right... I was thinking more about 64-bit support outside the wave intrinsics. E.g, you can pass them to various other random intrinsics like abs(), so the protos should get expanded, and so forth. Seems like mostly a separate thing from Wave*, but if it's subsumed under that bucket, then good enough. |
Agreed, I only meant the wave part of SM6 was added, not 64-bit in general. |
Hi! Regarding immediate (literal) samplers:
On the topic of dx9 sampler declaration: Cheers, |
About 1, no plans, and 2, right, the platform can't support it. There might be a scheme of indexing all literal possibilities and having the driver set them all up, to emulate it. Would maybe depend on what DXC does. 3, sounds likely, but that path is off/not supported. |
One issue I came across with namespace is that struct declarations aren't propertly scoped. struct Foo { float4 param; }; namespace Bar |
AFAIK they are pretty similar to the existing GLSL ones: sampler2D ms : register(s0); // layout(binding = 0) uniform sampler2D ms;
float4 main(in float2 uv : TEXCOORD0) : COLOR // or SV_TARGET, whatever
{
return tex2D(ms, uv); // texture(ms, uv);
} Thus it shouldn't be that hard to implement since the existing code for GLSL is present around there... |
how about using doc shaderc/glslc
|
Requested HLSL features. If it's checked, it's been implemented and working for some workload. If a checked feature is not working correctly, there should be an issue reporting the incorrect behavior. A missing feature should be requested here.
half
tofloat
. See issue HLSL: Halfs are not recognized as a type #492.PS_OUTPUT __output__ = (PS_OUTPUT)(scalar)
The text was updated successfully, but these errors were encountered: