Initial step toward HLSL code generation.

[tangent-vector]

• Split existing GLSL codegen into a shared base class, plus GLSL- and HLSL-specific subclasses.
  • Much of the code in the HLSL case is still copy-pasted from the GLSL case. Many fixes still needed.
• Clean up command-line argument parsing, and add option for HLSL output
• Adapt writing of stage input/output boilerplate for HLSL case, including:
  • Constant buffer declarations using HLSL syntax instead of GLSL
  • Write out struct type declarations for stage input/output
  • Generate main() entry points with struct input/output, and makes import/export use those variables
• Remap type names in a data-driven fashion
• Remap function names in a data-driven fashion
• Special case the handling of * operator when applied to at least one matrix (translates to mul() function call in HLSL)

Some notes/caveats:

• This code plays fast and loose with naming. In particular
  • I'm using names like stage_input and stage_output and just hoping they don't clash with user-defined names. It isn't clear to me right now how to "reserve" a name that is safe to use during codegen
  • The logic for remapping type/functions names doesn't distinguish builtin vs. user-defined symbols (I don't see how to do that in Spire), so it might end up renaming innocent user-defined symbols
  • The remapping steps currently use flat arrays and linear search; something faster will be needed eventually, but for now simplicitly wins over other concerns
• In order to handle the combination of user- and system-defined outputs, I construct both a struct TFoo type for the output record type and a struct TFooExt type that adds in the system-defined outputs (currently just the gl_Position equivalent).
• Looking at the way output/input "strategies" are currently used in the code, it seems like there is a big opportunity to clean this up and avoid allocation/indirection. For now I tried to avoid uncessary cleanup as much as I could.
• There's obvious a lot of stuff broken or not implemented in the HLSL output path. I'll claim that it is better to get something integrated early, and then fill in the gaps, rather than wait until it is perfect. This is especially true with the refactor I'm doing.

And the big one:

• I can't claim to have fully tested that these changes don't break GLSL codegen (since it was involved in the refactoring).

[hofstee]

If you prepend/append a string onto user defined variables you have a guarantee that anything not starting/ending with the string is fresh.

Alternatively you could rename all variables.

Both cases you mangle the readability a bit.

[tangent-vector]

Yes, adding a unique prefix/suffix to all user-defined symbols would be one option, but it would conflict with our goal of making the output code be as readable as possible. It would be especially bad if we renamed user functions or types, if we ever want users to be able to generate GLSL/HLSL from Spire that they can use with hand-written GLSL/HLSL.

A good long-term proposal might be to reserve some specific prefix like S<digits>_* and then ensure that all auto-generated symbols use that prefix (with unique digits generated from a counter), and then for any user-defined symbol that starts with the prefix (not expected to be common), or which conflicts with a keyword or other reserved name for the target, have a way of escaping it. A simple approach would take a symbol like S123_foo and make it S1_US123_foo, so that the S<digits>_U* prefix is reserved for escaped user-defined names.

I'd argue that any such policy is orthogonal to this pull request, since it doesn't look like the existing code for GLSL code generation was 100% robust against name conflicts (unless I missed something).

[csyonghe]

My solution to this is just to maintain a set holding currently used identifiers, and if a new identifier is already in the set, I will append a postfix. The naming will then be processed by EscapeDoubleUnderscore() function defined in Naming.h to make sure there aren't two consecutive underscores in the name.

[tangent-vector]

1. Can you point me to examples of how you use such a set in the existing GLSL codegen? I assume the data structure is already there, and I just need to use it.
2. Are you asking that I resolve this issue before you'll accept the PR, or are we just having an unrelated conversation. :)

Please let me know if there is anything you want me to fix before this PR is okay to merge. Otherwise I'll probably start working on the next steps in a distinct branch while I wait for this to get merged.

[csyonghe]

No, I am not asking you to resolve this issue now. I am testing my refined API and integrating your pull request now.

From: Tim Foley [mailto:notifications@github.com] Sent: Thursday, November 10, 2016 3:30 PM To: csyonghe/Spire Spire@noreply.github.com Cc: Yong He yonghe@outlook.com; Comment comment@noreply.github.com Subject: Re: [csyonghe/Spire] Initial step toward HLSL code generation. (#41)

1. Can you point me to examples of how you use such a set in the existing GLSL codegen? I assume the data structure is already there, and I just need to use it.

2. Are you asking that I resolve this issue before you'll accept the PR, or are we just having an unrelated conversation. :)

Please let me know if there is anything you want me to fix before this PR is okay to merge. Otherwise I'll probably start working on the next steps in a distinct branch while I wait for this to get merged.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/csyonghe/Spire/pull/41#issuecomment-259798990, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACh4haLVL5FzB2W1bl6o_65Peb95m1HBks5q837jgaJpZM4Ku6_0.