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

[phoronix]

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...

http://www.phoronix.com/scan.php?pag...en-Conformance

[miskol]

Nice move

[timofonic]

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.

[ms178]

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.

[pal666]

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?

[tomas]

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?

[juarezr]

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...

[tomas]

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.

[pal666]

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

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

[robclark]

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)