Announcement

Collapse
No announcement yet.

Khronos Opens Door For Allowing More Open-Source Drivers To Reach Conformance Status

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

  • Khronos Opens Door For Allowing More Open-Source Drivers To Reach Conformance Status

    Phoronix: Khronos Opens Door For Allowing More Open-Source Drivers To Reach Conformance Status

    Khronos president Neil Trevett was at this month's XDC2019 conference in Montreal and he clarified their position on accepting conformance submissions by the open-source drivers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Nice move

    Comment


    • #3
      Next moves that could also make Khronos standards gain even more adoption:

      - Proactively support Free/ Open Source Software projects, drivers or relevant software (game engiines, 3D modeling such as Blender, Libreoffice, CAD, CAE such as KiCad, etc): Have their own teams, contract companies (such as Collabora and Igalia, etc), efforts similar to Google Summer of Code, etc.
      - Merge standards and avoid segmentation as much as possible. My dream is they make Vulkan a DirectX competitor but a lot better and even covering lots more areas.
      - Convert it an open standard accepted by both national and international standards bodies: ISO, ECMA, BDS, ANSI, ACM, etc.
      - Make it a totally open standard, without fees but requiring certified processes. Concentrate on courses and education instead, just like others do.
      - Make Free/Open Source projects be part of technical and other decisions in Khronos, not second grade citizens please.

      Comment


      • #4
        Originally posted by timofonic View Post
        Next moves that could also make Khronos standards gain even more adoption:

        - Proactively support Free/ Open Source Software projects, drivers or relevant software (game engiines, 3D modeling such as Blender, Libreoffice, CAD, CAE such as KiCad, etc): Have their own teams, contract companies (such as Collabora and Igalia, etc), efforts similar to Google Summer of Code, etc.
        - Merge standards and avoid segmentation as much as possible. My dream is they make Vulkan a DirectX competitor but a lot better and even covering lots more areas.
        - Convert it an open standard accepted by both national and international standards bodies: ISO, ECMA, BDS, ANSI, ACM, etc.
        - Make it a totally open standard, without fees but requiring certified processes. Concentrate on courses and education instead, just like others do.
        - Make Free/Open Source projects be part of technical and other decisions in Khronos, not second grade citizens please.
        Just some remarks:

        1. The first one is very ressource intensive. Part of the problem is the organizational structure of Khronos, they are dependent on the will (and the funding) of their members and to reach large consensus and get the funds to promote some of these is hard, I suppose.

        2. Vulkan is already a DirectX competitior, could you elaborate more which areas need to be covered additionally?

        3. What gain should this bring? Vulkan is driven by hardware and software companies and governed by them, I don't see any additional benefit here to bring this forward to the standard bodies you mentioned.

        4. While not free, Khronos membership payments are pocket money for large companies and if I remember correctly they already waive fees for individuals who want to participate. I guess they need the fees to refinance some of their efforts (such as Nr. 1 would consume more of).

        5. I wonder if this is not already possible to a certain degree, see Nr. 4. What they don't want is that a large number of these projects could overrule the established hard- and software companies on technical decisions, I can understand this as having to implement some features could be more costly than others.

        Comment


        • #5
          Originally posted by timofonic View Post
          Next moves that could also make Khronos standards gain even more adoption:

          - Proactively support Free/ Open Source Software projects, drivers or relevant software (game engiines, 3D modeling such as Blender, Libreoffice, CAD, CAE such as KiCad, etc): Have their own teams, contract companies (such as Collabora and Igalia, etc), efforts similar to Google Summer of Code, etc.
          why would nvidia contract someone or have its own team to do driver for competitors?

          Comment


          • #6
            Originally posted by pal666 View Post
            why would nvidia contract someone or have its own team to do driver for competitors?
            Why would Red Hat contract someone or have its own team write code that is used by its competitors?
            Why would Intel or AMD contract someone or have its own team write code in Mesa that is used by its competitors?

            Comment


            • #7
              Originally posted by tomas View Post

              Why would Red Hat contract someone or have its own team write code that is used by its competitors?
              Why would Intel or AMD contract someone or have its own team write code in Mesa that is used by its competitors?
              A: Software Commoditization?
              When you sell hardware, writing supporting software is another cost.
              So sharing common software parts between vendors cuts the effort needed for building the whole software/driver/ecosystem.
              It already works in many others business around the world like fuel distribution, etc...

              Comment


              • #8
                Originally posted by juarezr View Post

                A: Software Commoditization?
                When you sell hardware, writing supporting software is another cost.
                So sharing common software parts between vendors cuts the effort needed for building the whole software/driver/ecosystem.
                It already works in many others business around the world like fuel distribution, etc...
                Yes, of course I know that. They were rhetorical questions in response to the non-rethorical question from pal666.

                Comment


                • #9
                  Originally posted by tomas View Post
                  Why would Red Hat contract someone or have its own team write code that is used by its competitors?
                  that's how opensource works. redhat is 100% opensource company
                  Originally posted by tomas View Post
                  Why would Intel or AMD contract someone or have its own team write code in Mesa that is used by its competitors?
                  because amd and intel use code written by everyone else in mesa. they are not writing drivers for nvidia. and you are suggesting nvidia to write drivers for someone else. nvidia can't write driver even for themselves

                  Comment


                  • #10
                    Originally posted by tomas View Post
                    Why would Intel or AMD contract someone or have its own team write code in Mesa that is used by its competitors?
                    So these #'s are for freedreno, but they should give a sense for other (especially gallium) drivers.. something like 20% of the code that goes into giving you a working GL driver is hw specific, and the remaining 80% is shared across drivers (mesa core, mesa state-tracker, and shared nir code make up the bulk of that, and there are some shared utils too).. intel uses some nir passes I originally wrote to glsl_to_nir path working for freedreno (and ofc I use a lot of nir passes they wrote), for example. At some point smart vendors realize there is a lot of benefit to working together on parts that everyone needs, vs everyone re-inventing the same wheel.

                    The balance shifts a bit with vulkan, given that it is a lower level API. But even the vulkan drivers in mesa share a lot (mostly nir, but also wsi and other utils)

                    Comment

                    Working...
                    X