Always doesn't indicate enough that this is past behavior. and as many as just read awkward to me. Also replaced the repeat of the word element with scalar.

Just to point out, DXIL has both fma and fmad. The valid overload set for fma is fp64, where the valid overload set for fmad is all floating point types. I assume that fma in this list is intended to refer to both, but it would be good to be explicit.

I did not intend it to refer to both as of yet. This is a very preliminary list of intrinsics that was handed to me. It does now occur to me that the source might have been under the impression that it encompassed fmad even though I took it to be strictly the double fma.

Makes sense. I was surprised at the tiny scope of opcodes listed here, but I assumed that the primary use case is not for doubles, so listing only fma without fmad confused me.

Fma in this list should only refer to the special double fma DXIL operation with specific precision requirements.

There is also the DXIL operation FMad, which supports some flexibility in precision requirements as long as they are the same wherever it is used on the same hardware.

I believe this list is about to be significantly expanded, and I hope to see Mad on this list as well.

This list is getting removed as we've determined that scalarized versus native elementwise intrinsics are an implementation detail.

As long as there's sufficient test content that all vectorized intrinsics are covered, I'm fine without an exhaustive list in the spec.

The exhaustive list is now the "allowed elementwise" list that was above this removed section.

Does this mean that long vectors can marked as groupshared and it just works? Wondering if this Q&A belongs in the DXIL spec?

groupshared is allowed. I don't list it as being disallowed, but I don't mind calling it out explicitly.

Maybe I'm missing the context or the significance of not including explicit Load/Store operations here, or just plain misunderstanding this Q/A altogether. The "preferred solution is outside the scope" seems to suggest that there's not going to be a way to use long vectors in groupshared.

It's not a feature that is directly connected with long nor native vectors. The core problem is that groupshared memory is limited and explicitly allocating it to one purpose is expensive. Instead, many users want to reuse groupshared memory for a few different purposes depending on stage and time.

There's some disagreement on how we can best solve this. We might provide what is essentially a groupshared rawbuffer with mechanisms to perform loads and stores on it similarly to how we do on global rawbuffers. That was the alternative approach previously described. There are more clever compiler things (tm) that could be done or other ways of enabling the user in this way.

Since it is not a problem directly connected with this, since there are a few different approaches we might take that would take a long time to decide on and implement, and since there are other solutions to the problem using existing mechanisms, we deemed it out of scope for this project.

Ok. I think that this Q/A is a bit confusing as written now. If I understand correctly, it's saying that we're not going to tackle solving the problem of people wanting buffer-like access to groupshared memory. So in the same way that we don't support explicit Load/Store operations for other data types, we're not going to add new ones for this. Marking a long vector as groupshared is still expected to work.

What you've said is accurate, so I don't know why you think it's confusing. I'm happy to take another run at it, but I think it's succinct and sufficient. It doesn't go into detail because I don't think we need to. It's a feature for another day. I could create an issue for it that could contain all the details if that would help.

I was only able to reach the understanding by this conversation.

groupshared is allowed. I don't list it as being disallowed, but I don't mind calling it out explicitly.

I did not intend it to refer to both as of yet. This is a very preliminary list of intrinsics that was handed to me. It does now occur to me that the source might have been under the impression that it encompassed fmad even though I took it to be strictly the double fma.

What is the reasoning for disallowing the conversion functions?

Sorry I didn't address this. Some of these comments didn't show up in my review of the files. I think you're referring to the as functions? There is some variability there. Some of them map to a simple bitcast. Those are fine. Some of them take multiple parameters representing low and hi bits that don't map as neatly.

I might phrase this differently. I think there are two big motivations for vectorizing DXIL.

Many GPUs support vector operations, and with DXIL today they must rely on auto-vectorization to re-materialize vectors late in the compiler. Auto-vectorization is a notoriously difficult compiler optimization that frequently fails generating sub-optimal code. Conversely scalarization is a trivial compiler transformation that never fails. Allowing DXIL to retain vectors as they appeared in source allows hardware that can utilize vector optimizations to do so more easily without penalizing hardware that requires scalarization.

-and-

One common complaint about DXIL is the size of compiled programs. Vector operations can express in a single instruction operations that would historically take N instructions in scalar DXIL. For this reason allowing vector preservation in DXIL may result in reduced file size for compiled DXIL programs that utilize vectors.

This is a better written version of what I was trying to say. I've integrated it.

How does this design accommodate N being supplied from a specialization constant supplied at runtime, rather than a literal value that is known at HLSL compile time?

Runtime specialization constants are not currently supported in HLSL. That's a question we'll need to answer when it is. For now, any similar mechanism produces an error: https://godbolt.org/z/5Kszf9Tr3 This includes the existing vk:: namespace specialization/push constant support.

error: non-type template argument of type 'uint' is not an integral constant expression

Does this include or exclude things like payload (DXR or mesh), attribute, or node record structures?

Testing scenarios below make it clear, but it should be clear here, and this should also include corresponding intrinsics that accept UDT values leading to these shader parameter types elsewhere.

We should also differentiate temporary limitations for the first implementation from limitations that have a good reason to be more permanent in the language.

Does this include or exclude things like payload (DXR or mesh), attribute, or node record structures?

Testing scenarios below make it clear, but it should be clear here, and this should also include corresponding intrinsics that accept UDT values leading to these shader parameter types elsewhere.

I've added a bit more detail here and gone into still more detail about the ray tracing interfaces that are disallowed in the diagnostics section. I think that's an appropriate place where here we can be more vague.

We should also differentiate temporary limitations for the first implementation from limitations that have a good reason to be more permanent in the language.

I thought we determined that we wouldn't draw such distinctions in this spec. It's my intention to document it as it will ultimately be, removing any references to temporary approaches. From context, I suspect you may think of this as a "temporary" approach? I don't think we are relaxing these restrictions as part of this shader model release. Mention of other possibilities might make sense in the "alternatives considered" section as potential future work, but otherwise, I'd prefer to leave it unmentioned.

Should we discuss alignment requirements at all here?

Do you have any suggestions on how that discussion might look?

I think this is part of the compiler testing which might belong in the HLSL spec where we describe how we verify DXIL and SPIR-V target IR output from the HLSL constructs. This is an area that crosses the spec boundaries, so it could go either way, but probably should live in one or the other and not both.

I don't want to keep playing the same note, but this is another comment that is born of our different perspectives on how these specs are divided up.

Should probably be a sub-section for validator testing. Basically, all validator testing is IR-based, since the compiler generally shouldn't be able to generate incorrect IR from valid HLSL. Valid cases are tested as part of testing the expected IR for each backend, which could be on the HLSL side. I feel like point form test scenarios is easier to review and break down further. Note that "type buffers" (typed buffers) is probably just looped in with "unsupported intrinsics".

More detail will probably be needed before implementation, but not before merging the proposal.

I agree this should be its own subsection and fleshed out.

Memory accesses operations should be separate from intrinsics that perform calculations (ALU ops). This wording seems to imply that you need to test ALU ops on different types of memory.

I was thinking of groupshared when I wrote this. I expect this is an anomoly of atomic operations, but they will lower into DXIL intrinsics or LLVM ops depending on whether the parameter is a groupshared variable or a resource element. Black box testing would indicate that we should ignore that we don't expect any such divisions because DXC doesn't provide them and when it comes to runtimes, some of it is a black box for us.

Do you think we shouldn't test groupshared as a separate state at least?

Here's where I think we describe testing for each supported backend IR. Shouldn't we be giving SPIR-V some love here as well?

Shouldn't there be a section before this that outlines various valid scenarios for AST testing?

For a given implementation, perhaps there would be an additional infra spec to outline tests for initial codegen and various important phases through the compiler as well, right? Perhaps the AST test scenarios belong there too?

Here's where I think we describe testing for each supported backend IR. Shouldn't we be giving SPIR-V some love here as well?

Definitely. I haven't done that research just yet. I've added a slightly hand-wavey allusion to the SPIR-V equivalent.

Shouldn't there be a section before this that outlines various valid scenarios for AST testing?

Have we done this in the past? I'm not sure what scenarios you have in mind. I'd like to see an example to better understand.

For a given implementation, perhaps there would be an additional infra spec to outline tests for initial codegen and various important phases through the compiler as well, right? Perhaps the AST test scenarios belong there too?

I think infra specs are useful to discuss forthcoming implementations. Given the state of this implementation, I don't think writing one would be as productive as carefully documenting what has been done in code and commit comments. I think that would be more likely to be preserved and found by future generations of coders.

Runtime specialization constants are not currently supported in HLSL. That's a question we'll need to answer when it is. For now, any similar mechanism produces an error: https://godbolt.org/z/5Kszf9Tr3 This includes the existing vk:: namespace specialization/push constant support.

error: non-type template argument of type 'uint' is not an integral constant expression

Does this include or exclude things like payload (DXR or mesh), attribute, or node record structures?

Testing scenarios below make it clear, but it should be clear here, and this should also include corresponding intrinsics that accept UDT values leading to these shader parameter types elsewhere.

I've added a bit more detail here and gone into still more detail about the ray tracing interfaces that are disallowed in the diagnostics section. I think that's an appropriate place where here we can be more vague.

We should also differentiate temporary limitations for the first implementation from limitations that have a good reason to be more permanent in the language.

I thought we determined that we wouldn't draw such distinctions in this spec. It's my intention to document it as it will ultimately be, removing any references to temporary approaches. From context, I suspect you may think of this as a "temporary" approach? I don't think we are relaxing these restrictions as part of this shader model release. Mention of other possibilities might make sense in the "alternatives considered" section as potential future work, but otherwise, I'd prefer to leave it unmentioned.

Do you have any suggestions on how that discussion might look?

I think execution testing may be the strongest argument for keeping it here. Long and native vectors aren't really interdependent and although the tests would likely share a lot of code, they should be independently testable in execution testing.

This is a better written version of what I was trying to say. I've integrated it.

This list is getting removed as we've determined that scalarized versus native elementwise intrinsics are an implementation detail.

In the interchange format section above we have:

Long vectors can be represented in DXIL, SPIR-V or other interchange formats as scalarized elements or native vectors.
Representation of native vectors in DXIL depends on dxil vectors.

This seems to imply that long vectors can be supported in existing shader models. I think it's only native DXIL vectors feature that actually requires SM 6.9?

That wasn't what I intended to imply with that statement, rather that implementations could choose either approach as we intend to do at least temporarily. However, it is true that this is possible. One of the major remaining questions is if we should.

Before I resolve this conversation: do we have something written down that is tracking this remaining question?

Ok. I think that this Q/A is a bit confusing as written now. If I understand correctly, it's saying that we're not going to tackle solving the problem of people wanting buffer-like access to groupshared memory. So in the same way that we don't support explicit Load/Store operations for other data types, we're not going to add new ones for this. Marking a long vector as groupshared is still expected to work.

Is this line needed for the long vector spec? It's probably implicitly assumed?