Create a POR for compiler/tool support and deprecation

[mikew-lunarg]

Members of the ecosystem would benefit from explicit plan-of-record regarding which toolchains are supported and when they'll be deprecated. Currently that seems ad hoc defined by individual projects, but is an opportunity for the Ecosystem TSG to add value.

It would allow developers to

• know which tools to use as the current shared baseline
• when to plan for migration as tools are deprecated
• which language features are acceptable

Information could include such issues as

• language-standards support: which C++ version? Is Python2 acceptable?
• platform-implementation support: What is the minimum Visual Studio version? When must we migrate to newer?

Motivation for this occurred recently when the Vulkan SDK attempted to deprecate VS2013 support, but found it necessary to revert, see LVL PR2261. If there was a shared understanding of the schedule, such effort could be avoided.

[danginsburg]

Good idea. Some feedback:

• steam-runtime defaults to gcc-4.8. I've occasionally seen breaking changes so it would be good to support that.
• VS 2013/2015/2017 use is still prevalent in our company. I'm not sure how many complaints you have received about not supporting VS 2010, but if it weren't that much effort I've seen devs still using it.
• For macOS, we still build on a pretty old Xcode 6.4 with OSX SDK 10.9. I'm not saying that should be the minspec (that's pretty old now), but just throwing out there that it's what we build on.

I can't provide feedback on Android NDK, but that's obviously an important target.

My personal view from experience (probably highly controversial, but I'll state it anyway) is that on libraries which are foundations for so many large code bases, we should go very light on modern C++ features.

[krOoze]

@danginsburg VS 2010 is not even supported by Microsoft anymore, but VS 2012 might be a gray area.

My personal view from experience (probably highly controversial, but I'll state it anyway) is that on libraries which are foundations for so many large code bases, we should go very light on modern C++ features.

Some foundational libraries usually go even further and have a C interface. So you are probably controversial in opposite direction than you thought :wink:

[KarenGhavam-lunarG]

It seems it would be good to make a list of the commonly used projects by Vulkan developers. And then for those projects build out a matrix of what is/is not supported. Then look for inconsistencies and try to get some alignment?

Here is a start at the project list (feedback welcome): SPIRV-cross SPIRV-tools glslang Vulkan-loaderAndValidationLayers Vulkan-Hpp VK-GL-CTS SPIRV-headers

[mtavenrath]

VS 2013 was the oldest one requested by people for Vulkan-Hpp and it has already some nice C++11 features. We shouldn't try to support really outdated compilers when it comes to modern APIs.

Maybe it'd be best if most of all toolkit libraries expose a C-based interface so that they can be used by older compilers in case someone really doesn't want to upgrade. Having a C-based interface am application can link too one can wonder if the library itself can use C++14/C++17 internally. As long as there is a modern compiler for the tools on the target system it can be used while the legacy application which gets an Vulkan backend can s compile against the old compiler for compatibility reasons.

Vulkan-Hpp shows that we have the tools to generate a decent autogenerated header only library on top of such a C-API to get access to modern C++ features. Such a library can also come in a limited version for older compilers or with and without RAII or exceptions depending on the developers use case.

Am 8. Dezember 2017 4:39:00 nachm. schrieb Petr Kraus notifications@github.com:

@danginsburg VS 2010 is not even supported by Microsoft anymore, but VS 2012 might be a gray area.

My personal view from experience (probably highly controversial, but I'll state it anyway) is that on libraries which are foundations for so many large code bases, we should go very light on modern C++ features.

Some foundational libraries usually go even further and have a C interface.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/8#issuecomment-350366287

[krOoze]

Maybe it'd be best if most of all toolkit libraries expose a C-based interface so that they can be used by older compilers in case someone really doesn't want to upgrade.

The rationale is more of a binding to other languages. I mean, whoever uses obsolete compiler on purpose probably deserves whatever problems he gets.

[mikew-lunarg]

To start a list of tools for a matrix (feedback welcome):

• VisualStudio (major versions; minor versions/patch levels)
• C++ standard (or make that implicit from the implementations below?)
• gcc
• clang
• MinGW?
• Android NDK
• python (2 and/or 3; minor versions)
• CMake
• git
• bash?
• powershell?

On Tue, Dec 12, 2017 at 8:09 AM, KarenGhavam-lunarG < notifications@github.com> wrote:

It seems it would be good to make a list of the commonly used projects by Vulkan developers. And then for those projects build out a matrix of what is/is not supported. Then look for inconsistencies and try to get some alignment?

Here is a start at the project list (feedback welcome): SPIRV-cross SPIRV-tools glslang Vulkan-loaderAndValidationLayers Vulkan-Hpp VK-GL-CTS SPIRV-headers

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/8#issuecomment-351079386, or mute the thread https://github.com/notifications/unsubscribe-auth/AVJooMGF4W8lcKHU8dE5BfEs3RgcsLDyks5s_pczgaJpZM4Q7isf .

[jjulianoatnv]

I wasn’t going to reply, but now I changed my mind.

whoever uses obsolete compiler on purpose

Control over the compilers available on some platforms isn’t in control of the users of the API, or even of the graphics driver vendor. It’s not uncommon to encounter an embedded platform that has a C++98 compiler, but not a C++11 compiler. This happens when the compiler has been modified by the embedded platform’s vendor to support peculiarities of the OS or the hardware, but the vendor does not invest in updating the compiler toolchain to support newer C++ dialects. Relying on C++11 or newer features can result in the library/package being unusable on these platforms. Even if the GPU vendor wants to support C++11 or newer, this might not be possible.

This is not to say that modern C++ must be avoided. But keep in mind that existence of a C interface means a library/header has increased potential to work on every platform. As someone else pointed out, bindings for non- C/C++ programming languages is often through a C interface.

From: Petr Kraus [mailto:notifications@github.com] Sent: Tuesday, December 12, 2017 1:05 PM To: KhronosGroup/Vulkan-Ecosystem Vulkan-Ecosystem@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [KhronosGroup/Vulkan-Ecosystem] Create a POR for compiler/tool support and deprecation (#8)

Maybe it'd be best if most of all toolkit libraries expose a C-based interface so that they can be used by older compilers in case someone really doesn't want to upgrade.

The rationale is more of a binding to other languages. I mean, whoever uses obsolete compiler on purpose probably deserves whatever problems he gets.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/KhronosGroup/Vulkan-Ecosystem/issues/8#issuecomment-351134695, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQrDOCkHlRka1Qz1fBkczDF6i-ITzdmMks5s_sBmgaJpZM4Q7isf.

---

This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

[krOoze]

@jjulianoatnv Heh, how could you not with such a bait. Emphasis "on purpose". Also let's remember C++11/14 predates Vulkan by a large margin. Besides, which custom embedded platform uses exclusively the popular VS 2013?

@mikew-lunarg Would for sanity make sense to assume that users use the latest minor version of the VS? Alternative C++ standard libraries (especially the choices in Android NDK)? Some of it could be represented in the form of supported distro. I.e. just "Ubuntu 14.04 + default repos"

[baldurk]

Note that the VS compiler version is not completely independent from the VS IDE version. Anyone using an older IDE cannot feasibly use a newer compiler and given the declining quality of the IDE that in itself is enough reason to use an older compiler, if a given project doesn't need anything newer.

Also bear in mind that many applications will have other considerations like static library dependencies compiled against a given VS version, the vulkan projects are not the only dependencies so supporting older compilers where at all possible avoids forcing people into difficulties.

[nsubtil]

From a discussion last week, we decided to start asking the various project leads for information on their minimum supported compiler / language feature set as a first step. This info will initially be made available in this repository.

We'll figure out what steps to take once we have that information.

[KarenGhavam-lunarG]

An update on this issue.

We have begun logging key projects in the ecosystem here. With each project we identify tool chain requirements. I did some cross checking with the repos we have documented in this list to make sure their README, BUILD, or CONTRIBUTING files indicate tool chain dependencies.

As new projects get requested to be added to this list, we will require that they document their tool chain dependencies before adding them.

[KarenGhavam-lunarG]

ISV Tool Requirements

Toolchain components and versions

The “Create a POR for compiler/tool support and deprecation” issue on the public Ecosystem GitHub proposes that some sort of statement be made about the toolchains that are used to build ecosystem components, including what versions are used and when versions are to be deprecated.

The discussion in the issue bifurcated into two areas:

Toolchains that are currently in use by projects

This is currently captured primarily in the README for the Ecosystem GitHub. The toolchain information therein is a consolidation of what the projects are currently using.

Toolchains in use by ISVs

Some ISVs contributed this information in the same GitHub issue, but much more needs to be collected, perhaps by surveying or other contact with ISVs. That small amount of input is captured in this document.

ISV Toolchain Input Data Summary

• C Standard

• C++ Standard

  • C++98 in use on some embedded systems (nvidia)
  • Users want libs written in C++11/C++14/C++17 (nvidia)
  • Should “go light” on C++ features in heavily-used libs(Valve)

• Gcc

  • Valve uses 4.8 in the steam runtime
  • Hans-K: The Android NDK toolchains were on GCC 4.8/4.9 for a long time. GCC 4.8/4.9 is a good baseline.

• Visual Studio

  • Valve uses 2013/2015/2017
  • Some devs using 2010 (unsupported by MSFT)
  • Krooze: 2012 is supported by MSFT and might still be in use
  • Baldur: Visual Studio compiler version can vary with VS IDE version (be careful)
  • Glslang submissions have sometimes been 2013 - but fixed to work on 2012
  • Unreal Engine 4 (as of 2015) uses 2013
  • Hans-K: MSVC 2013 is the first version to be useable for C++11 I think.

• macOS

  • Valve builds with Xcode 6.4 with macOS SDK 10.9

• Android NDK

  • No input, but important target to consider
  • Hans-K: Used to be GCC 4.8/4.9, these days, it’s quite modern Clang/LLVM.

• Library Interfaces

  • Strong support for “C” interfaces

    • Better for binding to other languages
    • Fewer problems with compiler versions

• Other tools that we might collect data on

  • minGW
  • Python 2, 3, minor versions
  • CMake
  • Git (?)
  • Shells
  • C++ Standard Libraries
  • Express in terms of Linux distros
  • Maybe create containers with “blessed” toolchains? (Karl)

[KarenGhavam-lunarG]

I believe this issue can be closed. If I don't hear otherwise in the next week I will close it. The steps that were taken:

1. Acknowledgement that it isn't practical to specify compiler tool chain versions for projects, because each project has it's unique constraints requiring various versions.
2. Instead, creation of the MAP of ecosystem projects that also documents the compiler tool chain requirements. As new projects are added to the MAP, their tool chain requirements are also documented.

[nsubtil]

I don't think we can close this issue yet. The most important point here is that, as originally requested, we need to help projects decide which compiler / toolchains to support.

We have a really good start based on the work that was done in documenting what we know today (which was posted in the comment above), but we're not done with this issue until we have run this by interested parties, set up a process for documenting this in a visible place and keeping that up to date.

[dneto0]

SPIRV-Tools is written in C++11. At one point we withdrew support for VS2013, and reinstated after a couple of weeks after feedback from Valve and LunarG.

SPIRV-Tools depends on:

• C++11
• Python 2 or 3
• For testing:
  • google/googletest
  • google/effcee, a library I wrote that itself depnds on google/re2 (RE2)
    • RE2 can't be built with VS2013, so the effcee-based tests are disabled by #ifdef when SPIRV-Tools is compiled with VS2013.

This week, googletest stopped working with VS2013. So we're about to decay our support so that:

• We will still build SPIRV-Tools with VS2013, but we won't test it.

This is not ideal, but I'm not willing to expend the resources to work around the problem for the sake of an old googletest. (E.g. a paranoid client of SPIRV-Tools could try pinning to an old googletest, but they would have to bear the cost of that.)

Stepping back, the Google Abseil library team has a 5 year support rule. https://abseil.io/about/compatibility:

We will support our code for at least 5 years. We will support language versions, compilers, platforms, and workarounds as needed for 5 years after their replacement is available, when possible. If it is technically infeasible (such as support for MSVC before 2015, which has limited C++11 functionality), those will be noted specifically. After 5 years we will stop support and may remove workarounds. ABSL_HAVE_THREAD_LOCAL is a good example: the base language feature works on everything except XCode prior to XCode 8 ; once XCode 8 is out for 5 years, we will drop that workaround support.

It's a simple-ish rule that I suspect will become common. For example, RE2 library stopped working with VS2013 earlier in 2018, and googletest stopped working with VS2013 just this week.

I'd like to assert something similar for SPIRV-Tools (and other components). It's too late for 2018, clearly. Can we get the ball rolling to agree on some date for VS2013 deprecation? How about "first release in 2019".

[nsubtil]

At the end of the day, deprecation should be driven by ISV feedback. They're the customers for this software stack.

Whatever we consider, we need to make sure we poll ISVs for feedback well ahead of time and be willing to change course based on that if needed. Unfortunately, at least in the games industry, the longevity of a given compiler version isn't really very predictable, so I'm a bit concerned that laying down a 5-year rule (or something along those lines) could backfire.

That said, I do think we need a more structured approach to compiler support. The cost of maintaining VS2013 support keeps coming up and it's definitely an issue.

I've pointed out in the past that adding in dependencies can be detrimental in this sense, and it seems a lot of the projects we end up depending on are not necessarily in sync with what we may need to do for Vulkan as far as compiler support goes. I'd like us to keep our mind open about this as well.

[dneto0]

At the end of the day, deprecation should be driven by ISV feedback.

There's apparent gap between what I'm willing to provide for free, and what ISVs may want. That sounds like a business opportunity. (Only half-facetious.)

That said, I think it could be useful to see what others are doing. For example, to use the DXIL flow, at least as of a few months ago I understand Microsoft requires you to select very-experimental Windows SDK support, i.e. bleeding edge. I don't know what Apple forces you to do, but I sense they tend to pull their developer community fairly quickly. I know Vulkan is in a different, much broader context.

But we're also talking about top-of-tree functionality as the Vulkan ecosystem evolves. If our developer community is truly stuck on old tooling, then what is their appetite for absorbing new Vulkan and SPIR-V features? If they don't need the new stuff then they can and perhaps should pin to old source versions of tooling. (E.g. CTS pins to specific SPIRV-Tools and Glslang etc.)

[johnkslang]

It's a big elephant being touch by different parties, so I think there is a finer-grained solution.

Here is a proposal for compromise for continuing 2013 support, based on the infrastructure needed to develop the tools being a superset of what ISVs actually need to compile with 2013.

1. Goal for all is that Vulkan/GLSL/SPIR-V tools proper, which ISVs want to incorporate into their tool chain or embed in products, keep compiling and working correctly on MSVC 2013. => Coders won't intentionally add non-2013 code to such tools.
2. The full dependency graph of development tools used by those developers to create/build/test the tools proper need not be limited to 2013 support; they can obsolete 2013 and be based on 2015 or later. => Testing of 2013 builds of tools proper may be lacking, but not overall quality otherwise.
3. When ISVs report 2013 problems/fixes, tool developers will officially fix tools to keep them working for 2013.

In this way, tool creators get some help from ISVs paying for the cost of maintaining 2013, while greatly reducing that cost by not keeping all the other tests/suites/compilers/etc. confined by 2013.

[marty-johnson59]

This repository is being archived as it has been replaced with the vulkan.org website (https://www.vulkan.org) and is no longer being maintained (i.e., issues posted here are no longer being addressed ). After reviewing issues posted here, most (if not all) have been resolved or have already been re-opened in Vulkan-Docs (https://github.com/KhronosGroup/Vulkan-Docs) or other repositories for further consideration. Therefore, all issues in this repository will be closed. If you believe your issue has not yet been resolved, please re-open in Vulkan-Docs. Thanks!