Announcement

Collapse
No announcement yet.

Confirmed: Vulkan Is The Next-Gen Graphics API

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

  • #21
    Originally posted by blackout23 View Post
    I hope it will work on all DX11 hardware (NVIDIA 400 series and newer). This would coincide with the hardware support of the current branch of their Linux drivers. DX12 is also supposed to work on all DX11 cards with varying levels of feature support however.
    didn't this change? i seem to remember reading they changed their mind and introducing 11.1 for those, while 12 will only work on new. but, as i said... i could just remember wrong

    Comment


    • #22
      Originally posted by mdias View Post
      I don't think there's a need for an OGL implementation on top of a lower level API. You will either want a simpler API than OpenGL (some kind of minimalist graphics engine) or you don't mind developing your own engine around the new API.

      I don't think the new API will be much harder to develop with if you already develop with OGL. Actually, if the shaders match HLSL better than current GLSL does, it will simplify the lifes of many developers.
      that's just wrong. implementing OGL on top of Vulkan would only bring benefits, since it would be software implementation running equally everywhere and all vendors supporting Vulkan would get 100% compatible OGL implementation.

      if nothing else, same shader would work everywhere and there wouldn't be performance gaps between vendors on extensions. not to mention how this would simplify driver and its deployment.

      Comment


      • #23
        Originally posted by log0 View Post
        I have to disagree. A compact, clean low-level API can be easier to deal with than a convoluted high-level monstrosity.

        The deciding factor for Vulkan adaption will be hardware support and drivers imho.
        For sure. And people can always make their high-level wrappers on top of that.
        With low-level access to all hardware features of the GPU, there will be less of a need for "opengl extensions" for new high-level features, people can then make their own stuff.

        Comment


        • #24
          Originally posted by justmy2cents View Post
          that's just wrong. implementing OGL on top of Vulkan would only bring benefits,
          It would only be a extra Layer. Most 3D Applications use a 3D engine for this. why not support the new api directly in the engine? A stable and feature completed opengl on top of vulkas would need years of afford. I guess this is a waste of time and manpower.

          Comment


          • #25
            Originally posted by d2kx View Post
            I think it's pretty likely that Google will support this in future versions of Android, because they want a competitor to Apple Metal and not only rely on OpenGL ES 3.1 + AEP.
            Quite likely so. However it's up to the likes of ARM, Qualcomm, Imagination, etc to write the "drivers" to allow use of this new API with their hardware. Given their history of buggy and outdated drivers, I'm rather pessimistic of this showing up on many devices soon. Google really needs to give them a good kick up the backside about driver development. Or maybe they could do something to help development of open drivers?

            The only manufacturer I could see quickly supporting Vulkan on their mobile hardware is Nvidia. Their desktop driver has long been very good, and with them using Kepler in the Tegra K1 (and Maxwell in the forthcoming X1), supporting their mobile hardware with the exact same driver is very little work. That is, assuming they decide to support Vulkan at all.

            Comment


            • #26
              Originally posted by efikkan View Post
              For sure. And people can always make their high-level wrappers on top of that.
              With low-level access to all hardware features of the GPU, there will be less of a need for "opengl extensions" for new high-level features, people can then make their own stuff.
              But it also means practically accepting de facto behavior what OpenGL was created to eliminate in first place. Sounds very self defeating to me.

              Comment


              • #27
                Originally posted by justmy2cents View Post
                that's just wrong. implementing OGL on top of Vulkan would only bring benefits, since it would be software implementation running equally everywhere and all vendors supporting Vulkan would get 100% compatible OGL implementation.

                if nothing else, same shader would work everywhere and there wouldn't be performance gaps between vendors on extensions. not to mention how this would simplify driver and its deployment.
                While what you say does make sense, there is much more at play than we can see at a glance. It could very well be possible that there is no direct correlation between an OGL API call and a Vulkan one.
                You also have the problem of OpenGL extensions. About shaders; you would have to translate GLSL to whatever Vulkan uses. What if the "gl_fragColor" equivalent on vulkan is supposed to have a slightly different behaviour depending on some pipeline state?
                This OpenGL wrapper could become so convoluted that it turns out to be worse than the original OpenGL implementation.

                I'm not saying it isn't possible, just that it probably isn't worth it.
                Last edited by mdias; 02 March 2015, 01:42 PM.

                Comment


                • #28
                  Originally posted by mdias View Post
                  While what you say does make sense, there is much more at play than we can see at a glance. It could very well be possible that there is no direct correlation between an OGL API call and a Vulkan one.
                  You also have the problem of OpenGL extensions. About shaders; you would have to translate GLSL to whatever Vulkan uses. What if the "gl_fragColor" equivalent on vulkan is supposed to have a slightly different behaviour depending on some pipeline state?
                  This OpenGL wrapper could become so convoluted that it turns out to be worse than the original OpenGL implementation.

                  I'm not saying it isn't possible, just that it probably isn't worth it.
                  agreed, i was more or less just answering to "I don't think there's a need for an OGL implementation on top of a lower level API" part. possible or not is probably beyond scope of anyone here unless they have been part of the development

                  as far as GLSL,... it would probably need to generate Vulkan shader IL, again beyond my scope of being able to say. just thinking that if HLSL->GLSL was possible, GLSL->Vulkan shader IL should be too
                  Last edited by justmy2cents; 02 March 2015, 02:07 PM.

                  Comment


                  • #29
                    Originally posted by Nille View Post
                    It would only be a extra Layer. Most 3D Applications use a 3D engine for this. why not support the new api directly in the engine? A stable and feature completed opengl on top of vulkas would need years of afford. I guess this is a waste of time and manpower.
                    backward compatibility with less cruft, easier drivers (same OGL could work everywhere where Vulkan is supported), fixing all that was wrong in games that will never be updated to Vulkan...?

                    that is only if Vulkan will really be as consistent as Khronos promised. Consistency between vendors in OGL is probably worst offender. making it perform as software layer on consistent runtime would also bring consistency to that implementation

                    Comment


                    • #30
                      I find it very plausible that there will be some sort of high-level graphics library implemented on top of Vulkan, for rapid prototyping and rapid application development. It sounds like a good idea to me. But we should take a long hard look at whether or not that API should be modelled on OpenGL-- it might be better to "start fresh" and implement something that maps more closely onto Vulkan's semantics.

                      It would be an opportunity to leave behind all the old design decisions that make OpenGL kind of awkward. For example, in OpenGL 4, glVertexAttribPointer still takes a pointer as an argument, but it's no longer legal to use it as an actual pointer (since OpenGL 3.3, I think?) It only gets used as an integer. Perfectly understandable given compatibility concerns and the history of the API, but I don't think anyone at Khronos is going to disagree that objectively speaking this is a stupid design.

                      It would also be an opportunity to leave behind all the "low levelness" that OpenGL had acquired with 3.x on. For example, why not bring quads back, or some kind of emulation of an immediate mode? Automatic "merging" of state changes where it makes sense?

                      In fact, a cleaner from-scratch high-level API that doesn't have to accommodate the fanatical optimizers (such as myself) and doesn't have to be compatible with older APIs, would be much easier to implement than OpenGL.

                      It could be that game engines would just fill this role, but I kind of hope not. These big commercial game engines are heavyweight solutions, and I kind of dislike the fact that it's become fashionable to pull in a dependency on, say, the entirety of Unity or UE, when you don't need 99% of that functionality.

                      Anyway, there simply isn't a chance that my current GPU will ever have Vulkan support, but I am incredibly excited about it-- this might be the year I put together a new computer.
                      Last edited by MaxToTheMax; 02 March 2015, 02:32 PM.

                      Comment

                      Working...
                      X