Page 4 of 4 FirstFirst 1234
Results 31 to 39 of 39

Thread: Feedback: New SPIR-V common intermediate language used by both OpenCL 2.1 and Vulkan

  1. #31
    I'd like to thank the SPIR-V folks for not only updating the SPIR-V preliminary specification, but also for keeping the bug database up-to-date. It's always good to see a bug database where bugs are quickly seen, assigned, acted on, and closed, where appropriate.

  2. #32
    Senior Member
    Join Date
    Mar 2015
    Posts
    176
    I believe I found a way to declare subroutines:

    subroutine uniforms are imported function declarations

    subroutines are exported functions of the same function type.

    Then in the api a spir-V module with a imported function is not fully linked but you can specify which exported function it imports.

    In openGL this can be transparent using the existing subroutine api. In vulkan a rendering pipeline will need a fully linked shader; failing to explicitly map the imported functions to an exported function should cause a failure.

    In fact a way to map the exported to imported functions even if the strings don't match will be helpful in general.

  3. #33
    Shader subroutines ultimately represent (I think) some kind of specific hardware within the system. As such, while your suggested implementation would be functional, I don't think it's in the spirit of the construct.

    It would also represent lots of recompiling of shaders. And I rather suspect that the point of subroutines is that it's (much) cheaper than recompiling shaders.

  4. #34
    Senior Member
    Join Date
    Mar 2015
    Posts
    176
    Quote Originally Posted by Alfonse Reinheart View Post
    Shader subroutines ultimately represent (I think) some kind of specific hardware within the system. As such, while your suggested implementation would be functional, I don't think it's in the spirit of the construct.

    It would also represent lots of recompiling of shaders. And I rather suspect that the point of subroutines is that it's (much) cheaper than recompiling shaders.
    OpenGL drivers recompile at the drop of a hat anyway (some gpus need a new program when you change blending state, some need a recompile when you change vertex layout, etc.) And drivers for gpus that have subroutine capability should be able to use it anyway.

    In vulkan this recompilation will only happen during pipeline/commandbuffer setup; a known expensive operation where it also optimizes the command buffer, why not let it take some time to inline the subroutine function calls.

  5. #35
    Newbie
    Join Date
    Jul 2015
    Posts
    1
    I recently started learning OpenCL. I thought I would make some effort at SPIR-V, but I find that a lot of information is more advanced than I can understand.

    One thing in particular I was confused about was the choice to use a binary representation (for instructions, I think). My sense of what I've read is that this choice was that the binary could provide better protection (IP, etc). Beyond this reason, is there a significant advantage as compared to how the original SPIR? For instance, is there a performance improvement? Further, would there be any benefit to 64bit when that is supported?

    I had another question, but it's not really specific to the specification, so feel free to ignore. I have read that there is work done on a SPIR-V to LLVM compiler, would it be possible to do something equivalent to building something on top of SPIR-V that is less portable but implements the system/io-related stuff that might be in LLVM but not SPIR-V?

  6. #36
    One thing in particular I was confused about was the choice to use a binary representation (for instructions, I think). My sense of what I've read is that this choice was that the binary could provide better protection (IP, etc).
    That's not really the point. SPIR-V as a language is easily processable, so users will be no less able to deprocess SPIR-V than any text-based intermediate representation. Text IRs don't necessarily use human-readable names for objects.

    The main reason for imposing a binary format is compilation performance, particularly the conversion from the input data to some form of AST or call graph or however one wants to internally represent the code. If you use text, you have to do a bunch of textual parsing stuff, comparing characters and strings and so forth. With binary, it's a switch statement.

    The binary format also makes it easy to jump over irrelevant data. For example, if you have some SPIR-V that contains text names for things (so that you can have decent debugging), if that SPIR-V were in a text format, then the parser would need to recognize that. It'd have to store identifiers and recognize them later. With binary SPIR-V, you can still label things, but the compiler can easily ignore such opcodes. Thus, in release builds where debugging information is not necessary, it's easy for such a compiler to just ignore all OpName, OpString, OpLine, etc opcodes. That's a lot less easy in text.

    Further, would there be any benefit to 64bit when that is supported?
    SPIR-V already has 64-bit addressing. So I don't see how a text format would facilitate that at all.

    would it be possible to do something equivalent to building something on top of SPIR-V that is less portable but implements the system/io-related stuff that might be in LLVM but not SPIR-V?
    That rather depends on what kind of "system/io-related stuff" you're talking about. Remember: the OpenCL execution model is limited compared to general systems level programming.

  7. #37
    A new preliminary spec is out. I'd guessed that 1.0 would have been done by now, but apparently not.

    Really good things that happened:

    1) You gave us an XML file defining the various integers associated with things, as well as several pre-generated headers/modules for a very wide variety of languages (though did the Lua one have to make the table global? ). This will make automated generation so much easier.

    2) No more texture variables. Textures are just a specialized type of "images". This makes the language so much cleaner, and probably works better for OpenCL.

    3) Actual linkage. It's very good that SPIR-V has linkage as a first-class feature. And it's also good that it's not restricted to Kernel, so that Vulkan could use it.

    Things I'm less sanguine about:

    1) Multiple entrypoints can be declared in the same module. I'm kinda "meh" on that one, because it stronly implies that Vulkan will require you to shove all of your shaders for a pipeline into one SPIR-V binary. And while SPIR-V is a fine IR, it is not easily compose-able.

    It sounds suspiciously like rewinding things back to the bad-old-days before we have ARB_separate_program_objects...

    2) You still haven't fixed bug 1330. Granted, there's a TBD on defining "uniform control flow", but "dynamically uniform" is still not strictly defined.

  8. #38
    Senior Member
    Join Date
    Mar 2015
    Posts
    176
    Quote Originally Posted by Alfonse Reinheart View Post

    1) Multiple entrypoints can be declared in the same module. I'm kinda "meh" on that one, because it stronly implies that Vulkan will require you to shove all of your shaders for a pipeline into one SPIR-V binary. And while SPIR-V is a fine IR, it is not easily compose-able.

    It sounds suspiciously like rewinding things back to the bad-old-days before we have ARB_separate_program_objects...
    And to find which input/output belong to which entrypoint you need to expand the static callgraph and see where they are used.

    It's also light on the details of what happens when 2 stages use the same input/output variables.

    (that's also my point in my other thread especially now that multiple entry points are allowed)

    Though to me it sounds more like "lets copy hlsl where a single file can contain the entire shader pipeline".

  9. #39
    Quote Originally Posted by ratchet freak View Post
    Though to me it sounds more like "lets copy hlsl where a single file can contain the entire shader pipeline".
    To me, it seems more like they were trying to support the ability to have multiple kernels (a common OpenCL practice), but never really gave much thought to the different needs of shader entrypoints.

Page 4 of 4 FirstFirst 1234

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean