Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 39

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

  1. #21
    I think you missed my point. As shown when you contradicted yourself:

    me: What if they have a function that uses a pointer already?

    you: That function should be changed to return a struct and would then get inlined

    me: What if they just do their job and write their translator to handle it?

    you: w00t one guy did his job correctly, now for all the other implementations

    That could just as easily be aimed at the previous case: everyone who's back-end works a certain way must change it. Thus putting "pressure on the optimizers", rather than anyone else.

    My overall point is that the current state of things only "puts pressure on the optimizers" for systems who's back-ends work a certain way. If the back-end happens to work SPIR-V's way, then there's no pressure at all. Therefore, your suggestion is only reasonable if you have knowledge that back-ends are more likely to work your way than SPIR-V's way.

    So please present said evidence.

    Equally importantly, this "pressure on the optimizers" must already exist. Why? Because any decently implemented back-end must accept the very real possibility that the user will want to pass return values back via pointers rather than through returning structs. Maybe it's an in/out value. Or whatever. It's the user's prerogative, and therefore, it's the optimizer's job to optimize that.

    And if it can handle it in the function case, there's on reason why it can't in the opcode case. Since this work must already be done... there's no point in changing this here.

  2. #22
    Senior Member
    Join Date
    Mar 2015
    Posts
    179
    the only reason modf even uses the out parameter is because the C function it copies does. That function was created in ye olden days where memory was faster than a flop and caches were a pipedream, then pushing that result to memory for later retrieval still made sense.

  3. #23
    Junior Member
    Join Date
    Mar 2015
    Posts
    5
    IMHO the big issue with returning a struct is that the operators are overloaded, but SPIR-V does not provide overloaded structs. So the spec would have to be something like modf returns a TwoDoubleStruct if the argument is of type double or a TwoFloatStruct if the argument is of type float, etc.

    I think the logical way to get rid of that pointer is to allow operators to define multiple result ids.

    OTOH I'm pretty sure that the presence of a "pointer" in the IR doesn't mean that the value will be stored in external memory, the GPU usually has a large register set and unlike x86, it can be accessed indirectly (so you could pass a reference to a register on the GPU).

  4. #24
    Senior Member
    Join Date
    Mar 2015
    Posts
    179
    Quote Originally Posted by mbentrup View Post
    IMHO the big issue with returning a struct is that the operators are overloaded, but SPIR-V does not provide overloaded structs. So the spec would have to be something like modf returns a TwoDoubleStruct if the argument is of type double or a TwoFloatStruct if the argument is of type float, etc.

    I think the logical way to get rid of that pointer is to allow operators to define multiple result ids.

    OTOH I'm pretty sure that the presence of a "pointer" in the IR doesn't mean that the value will be stored in external memory, the GPU usually has a large register set and unlike x86, it can be accessed indirectly (so you could pass a reference to a register on the GPU).
    Or have the spec contain something like

    "ResultType must be a structure type with 2 members, both members must be the same type as x. Member 0 contains the fractional part, member 1 the integral part."

  5. #25
    Junior Member
    Join Date
    Mar 2015
    Posts
    5
    Yes, but why add all this complexity ? The convention SPIR-V uses for single return parameters is to define a return id in the operator, so returning multiple values should naturally be encoded by multiple return ids.

  6. #26
    Senior Member
    Join Date
    Mar 2015
    Posts
    179
    I don't see them add the option to have multiple result IDs. Especially for only some extension opCodes.

    Remember the opcodes we are talking about are in the extensions and uses OpExtInst to execute which only provides a single return ID and its return type.

    That return type can then specify it's a structure type to specify it's a multivalued return. and use OpCompositeExtract to pull out the values

  7. #27
    Newbie
    Join Date
    Mar 2015
    Posts
    1
    This feedback forum is not immediately obvious from the SPIR-V registry on the khronos website. Instead it links to the Khronos bug tracker for feedback. As such, a few bug reports have been made there with suggestions and observations.

    Could someone please check those out?

    https://www.khronos.org/bugzilla/bug...resolution=---

    Thanks in advance.

  8. #28
    Senior Member
    Join Date
    Mar 2015
    Posts
    179
    a new revision of the provisional spec has been posted along side header files for the constants

  9. #29
    Hi, very much looking forward to future SPIR-V releases. A few comments and features I'd be interested in are listed below.

    - I've been very disappointed in OpenGL's 2d support for years, and increasingly so on embedded devices. On all major OS I can use the platform headers to get the front buffer directly but you cant really operate on even the back buffers directly with OpenGL/GLSL. Give us command support for this in the graphic operations. If people dont know how to handle it they don't have to. Its no problem for drivers. I dont want to always set up a whole dang 3D shader pipeline just to spit out pixels to a texture and blit it to a draw anymore..and I'm not alone.

    -Similarly, GPU-side draw call. For photo and video editing I can't even explain how useful this would be. Possibly allow us to set a duration for draw timing. Or mayber we could tell the driver, ok I'll get 4 frames pre-rendered into these buffers just keep drawing on rotation unless this register I set up says DEVICE_DRAW_STATE_INVALID or some such, then check with the CPU callback. Various approaches possible, any would be lovely.

    - In the presentation there was some question about the usefulness of compatibility with LLVM's representation. I think this is very useful indeed because many IDE tools are capable of taking advantage of LLVM's AST already in fairly advanced ways. This could prove especially helpful in developing new tools with similar functionality targeting SPIR-V.


    - Even though there's no goto / jump statements, I think it would be useful to be able to label individual lines or perhaps have comments. Really I think comments would be useful for adding further meta-data while avoiding the need to create our own file formats. Generated SPIR-V could be spiced with IDE cues without actually affecting the translated machine code. Perhaps you have a mechanism for this and I just glossed over it.

    - Developer-defined memory models. With the ability to control how memory is laid out and filled with data, or even being able constrain a pre-existing model in certain ways, developers could essentially have free garbage collection in C and C++ with some work.

    - Even though none of them are all that hard to emulate, I agree that thread_local storage, exceptions and basic reflection would be super nice, plausible and worth it.
    Last edited by Approach; 04-03-2015 at 02:06 PM.

  10. #30
    Senior Member
    Join Date
    Mar 2015
    Posts
    179
    Quote Originally Posted by Approach View Post
    Hi, very much looking forward to future SPIR-V releases. A few comments and features I'd be interested in are listed below.

    - I've been very disappointed in OpenGL's 2d support for years, and increasingly so on embedded devices. On all major OS I can use the platform headers to get the front buffer directly but you cant really operate on even the back buffers directly with OpenGL/GLSL. Give us command support for this in the graphic operations. If people dont know how to handle it they don't have to. Its no problem for drivers. I dont want to always set up a whole dang 3D shader pipeline just to spit out pixels to a texture and blit it to a draw anymore..and I'm not alone.

    -Similarly, GPU-side draw call. For photo and video editing I can't even explain how useful this would be. Possibly allow us to set a duration for draw timing. Or mayber we could tell the driver, ok I'll get 4 frames pre-rendered into these buffers just keep drawing on rotation unless this register I set up says DEVICE_DRAW_STATE_INVALID or some such, then check with the CPU callback. Various approaches possible, any would be lovely.
    That belongs on the vulkan side of things, with its gpu-side command buffers a "wait until vBlank" should be possible. Also 4 frames of latency is a lot for an action packed game

    Quote Originally Posted by Approach View Post
    - In the presentation there was some question about the usefulness of compatibility with LLVM's representation. I think this is very useful indeed because many IDE tools are capable of taking advantage of LLVM's AST already in fairly advanced ways. This could prove especially helpful in developing new tools with similar functionality targeting SPIR-V.
    I've been told that spir-V to LLVM is very easy to implement

    Quote Originally Posted by Approach View Post

    - Even though there's no goto / jump statements, I think it would be useful to be able to label individual lines or perhaps have comments. Really I think comments would be useful for adding further meta-data while avoiding the need to create our own file formats. Generated SPIR-V could be spiced with IDE cues without actually affecting the translated machine code. Perhaps you have a mechanism for this and I just glossed over it.
    that's already possible with the opLine opcode, it sets the line number and column number in a "file" that file could just be a list of comments that are being referred to

    Quote Originally Posted by Approach View Post
    - Developer-defined memory models. With the ability to control how memory is laid out and filled with data, or even being able constrain a pre-existing model in certain ways, developers could essentially have free garbage collection in C and C++ with some work.

    - Even though none of them are all that hard to emulate, I agree that thread_local storage, exceptions and basic reflection would be super nice, plausible and worth it.
    remember that spir-V has to run on today's openGL ES 3.1 compatible GPUs and as such is constrained by the lowest common denominator, they don't necessarily have room for the meta data needed to to manage all that

Page 3 of 4 FirstFirst 1234 LastLast

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