Announcement

Collapse
No announcement yet.

Why Wine Developers Don't See Gallium3D D3D9 As An Option

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

  • #81
    Originally posted by geearf View Post
    Hmmm, I think you are slightly mistaken about the differences between mesa and gallium3d.
    Intel writes mesa code that is still used by the other gallium3d drivers... (yes not all of Intel's code is reusable, OpenCL for example... but quite a bit is).
    Also, have you looked into GLAMOR that all radeonsi cards use (and probably amdgpu as well), it came from intel. It's also needed for the modesetting ddx...
    I think it's somehow understandable, Intel has the biggest dev team, moving to gallium3d with the goal to share more doesn't seem to counterbalance the amount of work they'd have to put in... Though they might accept a community-port of their driver if it's complete enough. And for Vulkan coming out next year, there is no need for a Gallium-like framework
    No, I've been reading the codebase, to scope out work required for Mali drivers, I understand the differences.
    Also OpenCL is huge, not a minor counterpoint. The costs of not using a shared infrastructure are much larger than what we lack today, it's what would have been.

    Again , I'm not blaming Intel for being what they are, which is a company.

    The inditement was on us, the user community which has no effective control nor easy entry points to fix the problems we face. And Vulkan? AMD and Valve *may* save us again, and they are the only ones who forge re-usable paths. This is why I buy AMD Products, if they finish ARM procs they may save us there also.



    Last edited by techzilla; 03 January 2016, 07:35 PM.

    Comment


    • #82
      Originally posted by techzilla View Post

      No, I've been reading the codebase, to scope out work required for Mali drivers, I understand the differences.
      Also OpenCL is huge, not a minor counterpoint. The costs of not using a shared infrastructure are much larger than what we lack today, it's what would have been.

      Again , I'm not blaming Intel for being what they are, which is a company.

      The inditement was on us, the user community which has no effective control nor easy entry points to fix the problems we face. And Vulkan? AMD and Valve *may* save us again, and they are the only ones who forge re-usable paths. This is why I buy AMD Products, if they finish ARM procs they may save us there also.



      I'm been interested in AMD Arm too., but the sound of things right now isn't good. It's my personal opinion so far that AMD isn't aiming for the traditioanl markets Arm products are found in. I don't think we'll be able to buy an AMD based Android phone anytime soon, if ever.

      Comment


      • #83
        Don't know what's going on with Gallium Nine, cause it rarely works with games. So far only WoW seems to work mostly with Gallium Nine.

        Comment


        • #84
          Originally posted by Dukenukemx View Post
          Don't know what's going on with Gallium Nine, cause it rarely works with games. So far only WoW seems to work mostly with Gallium Nine.
          Most games I've tried worked better with nine, a few were faster with nine, but alas also faster to crash...

          Comment


          • #85
            The problem with nine is that it's not reliable yet. For example https://github.com/iXit/Mesa-3D/issues/102 needs fixing before it can be recommended for any multiplayer game where people don't want to crash randomly.

            I had the mesa git + nine/staging branch installed and tried Heroes of the Storm again (hero test mode) and after about 5 minutes:
            err:gdi:GDI_CheckNotLock BUG: holding GDI lock

            Also this stack alignment issue https://github.com/iXit/Mesa-3D/issues/163 only seems to happen with nine and can be worked around by compiling llvm with -mstackrealign, but needs a proper fix in wine.

            Comment


            • #86
              Well to be fair, I don't think wine is reliable either so it'll be difficult for nine to be

              Comment


              • #87
                @techzilla

                The LLVM requirements for Gallium drivers can be really annoying for backports. Intel does not have that problem, so you can compile latest mesa for new Intel chips easyly.

                Comment


                • #88
                  Originally posted by Kano View Post
                  @techzilla

                  The LLVM requirements for Gallium drivers can be really annoying for backports. Intel does not have that problem, so you can compile latest mesa for new Intel chips easyly.
                  Which then brings us full circle, and leaves the path clear if we ever want to fix the problems I identified. However this is not related to Galium proper, but mearly the AMD OpenCL Backend. Would I love to throw out LLVM, YES YES YES.... did intel help us do that? Nope not at all, they always work alone.

                  Comment


                  • #89
                    Originally posted by Kano View Post
                    The LLVM requirements for Gallium drivers can be really annoying for backports. Intel does not have that problem, so you can compile latest mesa for new Intel chips easyly.
                    Can't you just take a newer llvm build for compiling mesa and use --disable-llvm-shared-libs?

                    Comment

                    Working...
                    X