Announcement

Collapse
No announcement yet.

Vulkan 1.0.9 Specification Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by justmy2cents View Post

    - if is much harder than basic OpenGL. only problem is that all those easy paths are long since deprecated and called slow paths. once you start dealing with VBO,IBO... OpenGL becomes much more complex and less understandable and as far as AZDO and later additions go, this explains it really well https://youtu.be/xXyZ4YaktyU?t=9164 . In modern GL drawing triangle is not few lines of code anymore as it was with glBegin/glVertex3f/glVertex3f/glVertex3f/glEnd
    https://youtu.be/EX1RKhlOYmY?t=2h11m41s
    Same video, much better resolution.

    Comment


    • #22
      One thing I forgot to mention - there were some comments about the initial Vulkan drivers not being able to run fullscreen (on Windows I think), but running "borderless" instead. Not sure how much that would affect performance but seems like it might be a factor. If there was an additional full-screen copy required every frame that could have some of the same "gap widens with resolution" effect as a slow shader compiler.
      Last edited by bridgman; 09 April 2016, 04:51 PM.
      Test signature

      Comment


      • #23
        Originally posted by norsetto View Post

        I was reading this just yesterday (http://www.aosabook.org/en/llvm.html) and I understood that a first optimization in llvm is done at the IR level. Still, I would expect some form of optimization to take place in the last compilation step as in principle during the IR processing phase one would know nothing about the target hardware.
        I must admit this whole Vulkan rigmarole is quite above my head right now, I dream of the day I may have drivers available on my machine so that I can start tinkering around...
        well, i said it in my previous comment. there are some that can fit in first level. like dead code removal as example. but, what is the point of making SPIR-V more complicated with no real benefit. SPIR-V is nothing but IR specification. this would complicate it by a lot. not to mention, that only some optimizations are generic enough, while many are probably better left to IHV because they know the fastest path for their hw

        note this example
        if (1 == 0) { // a lot of lines of expensive code } }
        with dead code removal, this will simply be dropped. but, main question here is? how do you define this in specification? will you create gazillion samples of such "invalid" code?

        what would be more than possible is some sort of standalone SPIR-V post processor that does what you say. feed SPIR-V and get out step 1 optimized SPIR-V and note the main thing here. both are same SPIR-V, so i cannot really figure out how optimization would fall into its scope. and since SPIR-V specification is completely open, nothing prevents people to write such tool

        update: this is just my opinion, but you really want to have at least one result that does exactly what you told it to. as soon as first possible result is optimized you're prone to find errors in that and if you have no exact reference, it makes job of assigning blame to find the root of the problem much harder
        Last edited by justmy2cents; 09 April 2016, 01:41 PM.

        Comment


        • #24
          Thanks for talking about this a bit, I forwarded the info to the original developer who sparked it, perhaps he will rethink Vulkan support in the future. I was trying to get him to reconsider it so that perhaps we could get Linux support at the end of development with Vulkan API but I just know very little about the whole issue so couldn't help.

          Comment


          • #25
            Originally posted by theriddick View Post
            Thanks for talking about this a bit, I forwarded the info to the original developer who sparked it, perhaps he will rethink Vulkan support in the future. I was trying to get him to reconsider it so that perhaps we could get Linux support at the end of development with Vulkan API but I just know very little about the whole issue so couldn't help.
            i doubt there will be much success. when someone screams "doomsday" on the first days of first beta drivers and first ever barely started port by citing 3rd party site that has no involvement with drivers or that port, he has probably already decided in his head and just wanted to get some public confirmation for his decision. guessing further, it was more like publicity stunt since nothing gets louder and more repeated than being controversial about currently hot topic
            Last edited by justmy2cents; 09 April 2016, 05:35 PM.

            Comment


            • #26
              As of today, the only spir-v compiler available is glslang, which, in their own words, is still experimental and not optimized. Then again, nothing prevents anyone to invent their own shading language and write up a spir-v compiler for it (I know at least one developer who might do just that ...). And of corse why not writing them in spir-5 itself?
              Last edited by norsetto; 10 April 2016, 12:31 AM. Reason: It could actually be fun to write a spir-5 shader

              Comment


              • #27
                Originally posted by norsetto View Post
                As of today, the only spir-v compiler available is glslang, which, in their own words, is still experimental and not optimized. Then again, nothing prevents anyone to invent their own shading language and write up a spir-v compiler for it (I know at least one developer who might do just that ...). And of corse why not writing them in spir-5 itself?

                Besides Time, Effort, and Money? :/

                Comment

                Working...
                X