Announcement

Collapse
No announcement yet.

Zink With Mesa 21.1 Now Advertises OpenGL 4.6

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

  • #21
    Originally posted by mangeek View Post
    I'm totally going to end up playing Stupid Nerd Games by trying to run Gnome on Wayland on Zink on Nvidia proprietary, just because it's ridiculous and the video memory will come from my MX250 instead of my Iris's allocation of RAM.

    Pray for me.
    I think you will need the "WIP: Penny" patch series to be merged before this works.

    Comment


    • #22
      Originally posted by mangeek View Post
      I don't think it -can- get to native speed for real-world use, but I'd look at it from the other perspective. Let's say GTK, QT, game engines, and new versions of CAD applications are all rendering to Vulkan in a year. The only time you're actually using the OpenGL API is for legacy programs. As a driver developer, are you going to code an OpenGL and a Vulkan driver, or are you just going to write a Vulkan one and let Zink handle the corner-cases and legacy stuff? I like that future; it's less work to do in exactly the place in the stack where the work is most valuable. Sure, the OpenGL stuff won't be as fast, but you'll probably see performance improvements for Vulkan AND OpenGL by focusing your driver development resources on just Vulkan, or occasionally contributing to Zink, and the Zink improvements help across the board.
      Legacy stuff is a serous pain with CAD. There are a lot of usages in buildings where you needing the cad models sometimes decades later.

      Remember total crap video outs with basically no GPU is going to exist. There is hardware that does not have the functionality to support Vulkan but does have the hardware to support opengl 4.6. There is horrible room for a vulkan to opengl that offloads as much as it can to opengl while emulating the functionality that the hardware does not support.

      Your idea that better to just write Vulkan driver then use Zink is possible long term valid in the cases hardware can in fact support vulkan.
      The needed parts going forwards.
      1) Legacy drivers for existing cards and New opengl drivers for GPU designs that hardware cannot support Vulkan but can support opengl.
      2) New cards where the existing legacy opengl drivers can simply be extented to support the new cards. Performance reasons here as this is resulting in less overhead.
      3) software rendered Opengl.
      4) Zink.

      Something to remember new features appearing in opengl is disappearing. Zink also shares a lot of opengl code with the amdgpu and Intel mesa drivers.

      Lot of people would not think there would be a usage case for Vulkan on Opengl horrible reality there is. Some of the problem here is you can make a MMU in the GPU that uses less silicon space if you don't support Vulkan in hardware yet still support full Opengl 4.6. Yes the fun of embedded hardware cost cutting.

      Comment


      • #23
        Originally posted by You- View Post
        What makes you think they arent? I havent read anywhere that they are gaming the numbers.
        you should read more, they(mesa) do "game numbers" when it makes sense. btw why they can "game numbers" in version bump, but not in mesamatrix?(see post i was replying to)

        Comment


        • #24
          Originally posted by rmfx View Post
          if it wasn't written join date: 2019 under my profile name...
          like you were smarter before 2019

          Comment


          • #25
            Originally posted by pal666 View Post
            you should read more, they(mesa) do "game numbers" when it makes sense. btw why they can "game numbers" in version bump, but not in mesamatrix?(see post i was replying to)
            yes. but where? Mesamatrix.net shows full compliance too.

            Normally when they game numbers, it is dscussed in an issue or a merge request where the reasons are discussed. Often something like "App/Game X required 4.2 but does not used 4.2 features" etc. I cant find any such discussion anywhere.

            Comment


            • #26
              Originally posted by markg85 View Post
              I'd like to hear a bit more about this only being an artificial version bump? curfew
              As on mesamatrix it also looks like all extensions are really implemented!
              Zink doesn't pass the official OpenGL specification test suite and also the only game it's being tested on keeps crashing. Mesa hardly requires anything more than advertising support in order to get a green checkmark in the feature matrix.

              Comment


              • #27
                Originally posted by atomsymbol

                glxgears does not render correctly, but Tomb Raider (2013) runs quite well at 5 FPS @2160p using Zink (compared to 30-40 FPS using native OpenGL). There seems to be an issue rendering back-facing triangles, screenshot:



                Hi atomsymbol. Could share a bit more. From which tree are you running zink? mesa master, or zmike zink-wip? Also what GPU? glxgears should render correctly, because I never had an issue with it actually over last 3 months of testing with zink. Also the Tomb Raider for me does launch only when using Ultimate quality settings (set without zink first), in other settings it crashes on startup. When using Ultimate quality settings it does start and shows menu (including 3D background), but launching a benchmark it crashes on first frame. If you could fill bugs for glxgears and Tomb Raider on mesa or zmike gitlab issue tracker, that would be great.

                Also, from my expirience performance should be better than what you are getting, even in complex titles. Usually about 60% can be achieved, so you should be getting close to 15 FPS. And in high resolution (which stresses GPU more than CPU), probably 80%, so close to 20 FPS. Weird that you are getting 5FPS, maybe you didn't enable optimizations / disable debug checks, when building mesa, or are using too much VRAM? Mangohud works pretty well with zink, and monitoring GPU and VRAM load is a good idea during such tests.

                Comment


                • #28
                  Originally posted by atomsymbol

                  mesa master.

                  Mesa doesn't report when it requires an Xorg restart in order to function correctly, so some rendering issues after a Mesa upgrade might be caused by this. (DRI driver in Xorg.0.log is radeonsi).

                  glxgears bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3167 (replaced by: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3177)

                  GPU: RX 5500 XT (8G VRAM)

                  "mesa-zink mangohud TombRaider" does work on my machine: there is an infinite recursive glxinfo invocation

                  "mesa-zink glxinfo" reports 42 less OpenGL extensions than native glxinfo.
                  Oh. Ok. For the mangohud you need to use mangohud from `develop` git branch on github. The fix for the glxinfo recursion didn't get into `master` branch yet.

                  Yes, mesa master is way slower than zmike's zink-wip. 5fps is not unexpected. Be sure zink-wip is way faster, and more and more patches (still 400 to go) are being merged into mesa master.

                  Comment

                  Working...
                  X