Skip to content
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

Updates for final Vulkan ray tracing extensions #2466

Merged
merged 9 commits into from
Nov 23, 2020

Conversation

dgkoch
Copy link
Contributor

@dgkoch dgkoch commented Nov 23, 2020

GLSL specs updates: KhronosGroup/GLSL#144
SPV spec updates: KhronosGroup/SPIRV-Registry#86

Depends on the following changes landing first:
SPIRV-Headers: KhronosGroup/SPIRV-Headers#182
SPIRV-Tools: KhronosGroup/SPIRV-Tools#4027

Update to final (non-provisional) SPIR-V capabilities
(includes review feedback)
- Change visibilty of findLinkerObjects.

See merge request GLSL/glslang!78
@dgkoch
Copy link
Contributor Author

dgkoch commented Nov 23, 2020

cc @johnkslang

Copy link
Contributor

@dneto0 dneto0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some failures are caused by using an older bison.
Using bison 3.7 will fix the "end of file" error messages

glslang/MachineIndependent/glslang_tab.cpp Outdated Show resolved Hide resolved
glslang/MachineIndependent/glslang_tab.cpp Outdated Show resolved Hide resolved
26(incomingPayload): 25(ptr) Variable IncomingRayPayloadKHR
27: TypePointer Input 10(int)
28(gl_SubgroupInvocationID): 27(ptr) Variable Input
31: TypeVector 10(int) 4
Copy link
Contributor

@dneto0 dneto0 Nov 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm getting a test difference around here:

-              31:             TypeVector 10(int) 4
-              32:             TypeInt 64 0
-              33:             TypePointer Input 31(ivec4)
+              31:             TypeInt 64 0
+              32:             TypeVector 10(int) 4
+              33:             TypePointer Input 32(ivec4)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't seen this issue...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also have not seen this.

Maybe that's because we're not watching Travis anymore and not seeing multi-platform test differences?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which bot tests are actually running all the tests and comparing results? Only Appveyor?

We lost Travis and added like 7 others instead, but I'm still unclear if they are all just build tests, whereas Travis tests 6 different execution environments.

@dneto0
Copy link
Contributor

dneto0 commented Nov 23, 2020

I also recommend updating the known_good.json file in the root source directory, to ensure we validate against updated SPIRV-Tools.

@johnkslang
Copy link
Member

johnkslang commented Nov 23, 2020

I get a bunch of these "Validation failed" messages locally, when the only thing I change is spriv.hpp, and the corresponding spelling changes in glslang. It should make no difference at all in the generated result, and I verified that for at least one result, but the rebuilt validator (same code base, just the new header) says "Validation failed" on an extra 16 ray-tracing tests.

Edit: Update, that was regarding the previous appveyor diffs shown here. Now, it is down to just one of those, and a couple other things.

@dgkoch
Copy link
Contributor Author

dgkoch commented Nov 23, 2020

@johnkslang @dneto0 I think I've addressed all the outstanding issues in the latest push, including updated spirv-headers and spirv-tools.

@johnkslang
Copy link
Member

I think this PR needs to move to use the latest spirv.hpp from SPIRV-Headers. (That's what I was doing locally, trying to make a PR to move to the latest header, but having a validator issue. In the meantime, discovered the header wouldn't match what's here anyway.)

E.g., see OpConvertUToAcclerationStructureKHR which is spelled more correctly in SPIRV-Headers as OpConvertUToAccelerationStructureKHR.

@dneto0
Copy link
Contributor

dneto0 commented Nov 23, 2020

(Thumbs up to using latest spirv-headers and spirv-tools. I haven't looked at the spelling of the acceleration structure)

@johnkslang
Copy link
Member

There are also differences in the switch statement for OpTerminateInvocation in spirv.hpp.

@dgkoch
Copy link
Contributor Author

dgkoch commented Nov 23, 2020

There are also differences in the switch statement for OpTerminateInvocation in spirv.hpp.

That seems to be a previous manual addition to spirv.hpp that seems to be missing in spriv-headers?

alelenv and others added 6 commits November 23, 2020 14:54
vulkan/vulkan#2230

- no layout specified should be same as std430
- explicitly test std140, std430, scalar layouts

See merge request GLSL/glslang!86
vulkan/vulkan#2374

Add support for ignoreIntersectionEXT and terminateRayEXT as block
terminator statements.

See merge request GLSL/glslang!87
And update mesh shader results
@dneto0
Copy link
Contributor

dneto0 commented Nov 23, 2020

I think I found a bug resulting in indeterminate ordering of the output of the 64-bit int type vs. the ivec4 type.
It doesn't seem related to this PR?!
I'll file a separate PR for it.

@dneto0
Copy link
Contributor

dneto0 commented Nov 23, 2020

Ah, this PR exposed the pre-existing bug with indeterminate order.

This is the fix:

$ git diff HEAD^
diff --git a/SPIRV/GlslangToSpv.cpp b/SPIRV/GlslangToSpv.cpp
index ba4264c2..a2494ec7 100644
--- a/SPIRV/GlslangToSpv.cpp
+++ b/SPIRV/GlslangToSpv.cpp
@@ -2122,8 +2122,9 @@ std::pair<spv::Id, spv::Id> TGlslangToSpvTraverser::getForcedType(glslang::TBuil
             // these require changing a 64-bit scaler -> a vector of 32-bit components
             if (glslangType.isVector())
                 break;
-            std::pair<spv::Id, spv::Id> ret(builder.makeVectorType(builder.makeUintType(32), 4),
-                                            builder.makeUintType(64));
+            spv::Id ivec4_type = builder.makeVectorType(builder.makeUintType(32), 4);
+            spv::Id uint64_type = builder.makeUintType(64);
+            std::pair<spv::Id, spv::Id> ret(ivec4_type, uint64_type);
             return ret;
         }
         // There are no SPIR-V builtins defined for these and map onto original non-transposed

The problem is that evaluation order of arguments is unspecified. It's compiler-dependent. So enforce an order.

@dgkoch ^

@dgkoch
Copy link
Contributor Author

dgkoch commented Nov 23, 2020

Updated to the latest spirv.hpp in this CL (early on).

@johnkslang
Copy link
Member

So, #2468 passes the bot tests and has the same base known_good as this one.

Maybe it should go in first. (After looking into the non-determinism.)

@dgkoch
Copy link
Contributor Author

dgkoch commented Nov 23, 2020

So, #2468 passes the bot tests and has the same base known_good as this one.

Maybe it should go in first. (After looking into the non-determinism.)

I'd rather not put that one in. It'll conflict with all the test updates in this one.

@dneto0
Copy link
Contributor

dneto0 commented Nov 23, 2020

(Sorry, I should have been clear. The indetrminate order issue is not a bug: generated code was always correct. But it interferes with maintaining checked-in tests. This PR was the first to exercise the issue.)

@johnkslang
Copy link
Member

(Sorry, I should have been clear. The indetrminate order issue is not a bug: generated code was always correct. But it interferes with maintaining checked-in tests. This PR was the first to exercise the issue.)

But, historically (until a few months ago?), we would also have considered this an error, because we require getting the same test results on multiple compilers to pass the bot tests and turn green. I have fixed similar things before, due to that.

I'm worried this means we've dropped that kind of testing barrier in recent times, at least in part due to Travis CI not running.

@johnkslang
Copy link
Member

johnkslang commented Nov 23, 2020

I'd rather not put that one in. It'll conflict with all the test updates in this one.

If we put it in, this one would need a rebase. If we don't put it in, we need to manually sign off that we verified the header is identical to SPIRV-Headers (what I was doing that discovered some of these issues), which is probably acceptable.

For normal process in the future I highly recommend:

  1. a PR that updates to the latest headers and tools, both the actual SPIRV/spirv.hpp and in the "known_good"
  2. a follow-on PR that adds the new functionality, where the headers/tools are not changed

Authored-by: David Neto <dneto@google.com>
@johnkslang
Copy link
Member

The non-determinism made appveyor get the other result.

Let's fix that as well, and see all the bots passing, before doing the merge. I think it's okay to do that as part of this PR; just one more small update to it.

@dgkoch
Copy link
Contributor Author

dgkoch commented Nov 23, 2020

Added David's patch from above.
The included spirv.hpp should exactly match what's in SPIRV-Headers.

@johnkslang johnkslang merged commit ffccefd into KhronosGroup:master Nov 23, 2020
@dgkoch dgkoch deleted the khr_rt_final branch November 23, 2020 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants