Let’s ignore for the moment the question of whether SPIR-V is “blindly copying” anything and ask something more important:
Objectively speaking, does it matter?
SPIR-V is an intermediate language. You won’t be writing in it. You won’t be reading it, except when writing a shader compiler and checking what it generates. So long as the IR provides reasonable access to what the hardware can do, so long as it provides a solid abstraction, and so long that tools can manipulate it without much trouble… what does it matter if it looks more like GLSL than is strictly necessary?
Is that going to inhibit the ability of compilers to optimize code? Is that going to inhibit the ability of users to develop shading languages with whatever behavior they want to expose to the user? Is that going to break offline optimizers or reduce the functionality of other offline processing tools. Will that in any significant way negatively impact SPIR-V’s utility as an intermediate representation?
So why does it matter?
On your actual question, you wanted “some indication that they took a long and hard look at the entire thing instead of blindly copying from glsl”. Well, what would such an indication look like? You seem to be suggesting that the only reason SPIR-V uses global interface variables is because GLSL did, that if they built SPIR-V without looking at GLSL at all, they would obviously make them function parameters.
That’s assuming your own conclusion. Namely, that function parameters are obviously the one correct way to go, and the only reason not to use them is because you’re copying from GLSL.
HLSL was created from scratch, based on whatever Microsoft wanted. GLSL was initially developed by 3D Labs, who unlike Microsoft actually bothered to investigate other shading languages in use at the time. They patterned all of GLSL after Renderman. Remember
varying? That was from Renderman, as is the term
I would hope that you aren’t suggesting that Pixar was preemptively avoiding HLSL when they wrote Renderman. No, GLSL and SPIR-V did not pick this model because the developers hate HLSL.
There are good reasons why Renderman, and its derivatives, use this model. The most important of which is module linking.
It makes linking modules easier, with implicit rather than explicit interfaces between modules. If a module needs some input parameter, it just declares it; the module that uses it doesn’t have to change. This means that the interface variables are an implementation detail of other modules; the main module doesn’t have to know or care about them. Just like with other elements (images/textures/buffers/etc), you don’t have to shuffle values around from the main module to submodules if they require one.
This is just encapsulation, at the module level.
SPIR-V is not “blindly copying” from GLSL. It is simply making GLSL’s choices because it has similar needs. Module linking is an important feature of SPIR-V, and global interfaces are the only way have fully encapsulated, reuseable modules.
Please note: GLSL and SPIR-V (and Renderman) have module linkage; HLSL does not.
So I fail to see the need for any “indication” here. The choice is being made because it makes the most sense for the features of the system.
Yes, and that provides access to a genuine hardware feature of shaders, which would not be available in the old model (not that you can access it via Vulkan, since you have to put your OpImageSampler commands up-front).
What you’re asking about is ultimately just syntactic sugar.
Or to put it another way, separation between images and samplers is good because it’s useful, not because it matches HLSL. It’s not something you could layer over top of SPIR-V in your source shading language.