Announcement

Collapse
No announcement yet.

Zink OpenGL-On-Vulkan Now Nearly At ~69% Of Intel's Native OpenGL Driver

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

  • #21
    Originally posted by GruenSein View Post

    ...no reason why an OpenGL driver should not be multi-threaded while talking directly to the hardware... If anything, Vulkan is a slight restriction versus native access to the hardware.
    I think we should all keep in mind that 'OpenGL talks directly to hardware' hasn't been true for a long time. There's a layer of abstraction in there no matter what stack you're on. I'm pretty sure that even proprietary vendor drivers are using a layer of abstraction to make their jobs easier.

    I can absolutely see how Zink could end up making life easier for everyone by automatically delivering a fully-functional, if slightly slower OpenGL to anyone who can get a Vulkan driver running. That's a huge win. If a vendor wants to invest $BIG to write a more 'native' path from OpenGL APIs to their metal, they still can, but I'm guessing that there's more value in optimizing the Vulkan driver for the silicon that runs under it. I'm pretty sure that today's metal is sufficient for most -visual- workloads, and that most of the need for more performance is driven by the compute side.

    Comment


    • #22
      Originally posted by mdedetrich View Post
      This is half of the story, there are other reasons why Vulkan is much better for multi-threading is that the main OpenGL context uses global state and many OpenGL drivers were built this way (this gets to my earlier point). If you ask a lot of game devs about doing multi-threading in OpenGL, a lot of them would have not nice things to say. OpenGL was made in the 70s (iirc) and back then everything was your typical "C based global state" style program and the API reflected this.

      Vulkan on the other hand uses immutable data structures and takes a much more "functional" approach (i.e. no global state). This makes it much easier for both the driver/library and the library users.
      Vulkan doesn't have that global state, but Zink does. Because it implements OpenGL, so it has the same API limitations as any other GL driver.

      Comment


      • #23
        Originally posted by SteamPunker View Post
        I expect future GPUs to only get Vulkan drivers in Linux, relying completely on Zink for OpenGL support.

        Also, once Zink can be used on top of MoltenVK, it will finally allow the use of newer OpenGL versions on macOS as well, since Apple deprecated OpenGL in favor of their proprietary Metal API and froze their OpenGL support at an earlier OpenGL level 4.1 or 4.2, I believe).
        Why should existing OpenGL drivers be removed? That's silly thinking. I consider Zink more of a playground for interested developers with possible use on Macs. Also some developers might want to continue in Vulkan, without rewriting all their existing opengl code.

        Comment


        • #24
          Originally posted by mike456 View Post

          Why should existing OpenGL drivers be removed? That's silly thinking. I consider Zink more of a playground for interested developers with possible use on Macs. Also some developers might want to continue in Vulkan, without rewriting all their existing opengl code.
          Read my post again. I didn't say anything about removing existing OpenGL drivers. What I wrote is that I expected that newer generation GPUs wouldn't be getting OpenGL drivers in Linux anymore. Instead, driver developers will be able to focus exclusively on Vulkan drivers, with Zink providing OpenGL compatibility on top of that.

          You've seen the percentage of recent performance gains mentioned in the article. If Zink is already near 70% of the performance of the highly optimized Intel OpenGL driver on the same hardware, as such a young project with only one developer so far, than this has the potential to make native OpenGL drivers redundant.

          Keep in mind that most OpenGL drivers in Linux already rely on a lower abstraction layer, namely Gallium3D. This was done to reuse as much code as possible between the various GPU-specific drivers. In a way, Vulkan is even lower-level than Gallium3D, since Vulkan (as I understood it) doesn't even have a state tracker. So why not run a universal OpenGL driver on top of Vulkan instead?

          So no, I'm not advocating the retirement of OpenGL drivers for existing GPUs, at least not until Zink meets or exceeds them in compatibility, stability, completeness and performance. Only at that point should existing OpenGL drivers be deprecated.

          But for future GPUs for which Linux drivers don't yet exist, I say, focus exclusively on the development of good Vulkan drivers and the further optimization of Zink as a cross-GPU OpenGL wrapper. That seems a much more efficient allocation of developer effort to me, especially given that more and more games and other software are expected to use Vulkan instead of OpenGL anyway.
          Last edited by SteamPunker; 17 October 2020, 05:20 AM.

          Comment

          Working...
          X