Announcement

Collapse
No announcement yet.

Zink OpenGL-On-Vulkan Looking Quite Good & Shining With Mesa 22.1

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

  • #21
    Originally posted by uid313 View Post

    Why is Zink losing at lower resolutions, and can anything be done about it?
    If so, what can be done about it, and can you do it?
    I think I could probably do it, but I've never been a Mesa contributor (except complaining about crashes in the GLSL parser and doing nothing to fix them) and I have an unrelated full time occupation o so it's unlikely that I will be the one to do it.

    I don't have deep knowledge of Zink either, so if there are big fish to fry I wouldn't know what they are; but once the big fish are fried it's probably a thousand minnows from there.

    Comment


    • #22
      Originally posted by [email protected] View Post

      In CPU-limited scenarios, zink is also going to compete for CPU time...
      Keep in mind though that the OpenGL implementations also compete for CPU time with the application (which is why Mantle/Vulkan were created); it's not necessarily the case that Zink + RADV is gonna be doing more work than RadeonSI.

      Comment


      • #23
        Originally posted by oiaohm View Post
        I would say at least for another decade we are going to still need some direct opengl drivers. There is hardware still being made that does not have the features to directly support being driven by a vulkan driver.
        So this is not necessarily a big issue, at least with Vulkan drivers in Mesa, equivalent features and modes can be exposed through Vulkan where necessary.

        Originally posted by oiaohm View Post
        Also Zink going Opengl->zink->Vulkan->hardware there is going to be some performance issues that show up in that level of abstraction.
        Native GL drivers also have layers of abstraction internally. On an architecture level, you could consider Vulkan to be replacing Gallium3D in Zink (not really, for the time being, but conceptually). The one bit that stays is a shader round trip (NIR to SPIR-V to NIR) but I think that is likely quite small in the grand scheme of things.

        It'd be interesting to see a fork of Mesa that's just Zink, where all of the abstractions and dispatches are factored out to leave a clean OpenGL implementation on Vulkan; then you could do the opposite trick to the rest of Mesa: delete all the OpenGL drivers and infrastructure, leaving only clean Vulkan drivers.
        Last edited by microcode; 12 May 2022, 09:20 PM.

        Comment


        • #24
          Originally posted by microcode View Post
          It'd be interesting to see a fork of Mesa that's just Zink, where all of the abstractions and dispatches are factored out to leave a clean OpenGL implementation on Vulkan; then you could do the opposite trick to the rest of Mesa: delete all the OpenGL drivers and infrastructure, leaving only clean Vulkan drivers.
          Mr. Ekstrand had said that it was a possibility to only be maintaining the zink and d3d12 drivers in the not far but not close future. this would likely include OCL, any directx targets like d3d10umd and G9, the possible Glide API so on and so forth

          EDIT: I should mention that it was a minor comment. so probably don't take much stock of it. but if he says the possibility is there, even in an comment on a PR, I think that the possibility is not a weak one.
          Last edited by Quackdoc; 12 May 2022, 11:49 PM.

          Comment


          • #25
            I wonder if someday this will be a way to get a working OpenGL implementation on macOS, if combined with MoltenVK.

            Comment

            Working...
            X