Announcement

Collapse
No announcement yet.

Microsoft Wants To Add DirectX + HLSL Support To The Upstream LLVM/Clang Compiler

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

  • khanich
    replied
    Originally posted by dragon321 View Post

    Actually the page you mentioned states that GCC has near complete support for C++20 features. The only thing that is only partially implemented is modules, rest are fully supported. As goes for standard library most C++20 features are supported as well. Only few are supported partially or not yet supported. Clang support for C++20 is worse than GCC but not very much, most features are implemented as well.

    Yes, it's true that MSVC currently supports all C++20 features but I wouldn't call GCC or Clang support "nowhere near". Both have almost complete support for this standard and only few things are missing or partially implemented.
    Well, I consider Compiler and standard library as one package since they depend on each other (for example look at coroutines or std::initializer_list).

    About partial features: the site doesn't tell you how far the implementation is. Is it 10% completed? Is it 90% completed? Both are considered partial.

    If we go by amount of features, yes, they are pretty close, but if we go about the sizes of the features, no, they aren't yet.

    Modules, "The One Ranges Proposal" and text formatting are all parts which are pretty big.
    In case you don't know, here a very simplified explanation of these:
    • Modules has to do with you you import libraries (no #include anymore for these, although you can also use them as a complete header replacement which some people are going to do).
    • "The One Ranges Proposal" essentially goes and replaces iterators (pairs) and allows lazy computation of values (you can essentially pipe things together like in a shell).
    • text formatting is parts of the fmt library standardized (https://github.com/fmtlib/fmt) and these things always require A LOT of work (seriously, it took GCC until version 11 to completely support "Elementary string conversions" from C++17 and Clang still hasn't complete support)
    Not only that, Microsoft already completed C++20 nearly a year ago.

    But well, this was mostly about the "I think Microsoft will eventually deprecate MSVC and fully embrace LLVM.".

    Leave a comment:


  • dragon321
    replied
    Originally posted by khanich View Post

    Considering that Microsoft is these days leading in implementing new C++ feature first, I doubt that.

    MSVC already has implemented all C++20 features (the same goes for Microsoft's standard library implementation).
    Both, GCC and Clang, are nowhere near, yet.

    A few example of big features that aren't implemented (and declared stable) yet:
    - formatting (std::format)
    - <=> support in the standard library
    - std::stop_token and std::jthread
    - "The One Ranges Proposal"
    - Calendar and timezone
    - modules
    - coroutines
    (If you want to read into it: https://en.cppreference.com/w/cpp/compiler_support)
    Heck, GCC is faster than Clang too.
    Actually the page you mentioned states that GCC has near complete support for C++20 features. The only thing that is only partially implemented is modules, rest are fully supported. As goes for standard library most C++20 features are supported as well. Only few are supported partially or not yet supported. Clang support for C++20 is worse than GCC but not very much, most features are implemented as well.

    Yes, it's true that MSVC currently supports all C++20 features but I wouldn't call GCC or Clang support "nowhere near". Both have almost complete support for this standard and only few things are missing or partially implemented.

    Leave a comment:


  • khanich
    replied
    Originally posted by amxfonseca View Post

    I think Microsoft will eventually deprecate MSVC and fully embrace LLVM.
    Considering that Microsoft is these days leading in implementing new C++ feature first, I doubt that.

    MSVC already has implemented all C++20 features (the same goes for Microsoft's standard library implementation).
    Both, GCC and Clang, are nowhere near, yet.

    A few example of big features that aren't implemented (and declared stable) yet:
    - formatting (std::format)
    - <=> support in the standard library
    - std::stop_token and std::jthread
    - "The One Ranges Proposal"
    - Calendar and timezone
    - modules
    - coroutines
    (If you want to read into it: https://en.cppreference.com/w/cpp/compiler_support)
    Heck, GCC is faster than Clang too.

    Leave a comment:


  • Smurphy
    replied
    Originally posted by dragorth View Post
    Well, as it would be in LLVM and presumably maintained by MS themselves, it could be used by anyone, including DXVK and Mesa. It would still require some work, but could be more compatible that the current solutions, or at least have different bugs.
    This just reminds me of Microsoft constantly adding a new UI on a rotten base.
    I prefer something simple and clean, not controlled by a corporation - especially not Microsoft, Apple or Google!

    Leave a comment:


  • mSparks
    replied
    Originally posted by kpedersen View Post

    Strongly agree. Independent companies, no matter how big they are just can't keep up.

    It would be nice to weaponize this fact a little more. For example:

    "No Microsoft, you will have to maintain your HLSL stuff out of tree because you consistently demonstrate that you are a bunch o' nobs"

    Same with Intel and their potential "pay as you go" hardware activation. Sure this has existed in various forms for a while but the open-source community should be making it as hard as possible for them rather than giving them the convenience of it residing in the upstream kernel tree.
    Glad Im not the only one who has noticed.

    There are some caveats, such as in certain highly specialist areas that require a lot of investment like graphics and aviation that are pretty sticky.

    But just how far ahead vast numbers of gpl programs have gotten over their closed source competition seemed untenable even just 5 years ago.

    Leave a comment:


  • ⲣⲂaggins
    replied
    Originally posted by Old Nobody View Post
    Whatever Microsoft does: I can't forget that they're following the "Embrace, extend, and extinguish" (EEE) strategy, very popular among the big commercial players.
    Seems more like EEE in reverse. "Here's an open-source compiler for a language we previously used as vendor lock-in."

    Leave a comment:


  • Old Nobody
    replied
    Whatever Microsoft does: I can't forget that they're following the "Embrace, extend, and extinguish" (EEE) strategy, very popular among the big commercial players.
    "Embrace" was WSL and the buy of Github. They're in the "extend" phase now. Alphabet, Amazon and Meta are in "extinguish" in their areas.

    Leave a comment:


  • Teggs
    replied
    Originally posted by Phoronix
    Microsoft... ...contribute... ...Vulkan graphics support...
    *checks*

    No, not April yet.

    Leave a comment:


  • Quackdoc
    replied
    This is kinda neat.

    Leave a comment:


  • CochainComplex
    replied
    Originally posted by skeevy420 View Post



    That would be my guess. I assume that anytime I see statements similar to: "While we could do this in our own fork".

    I have to imagine that there's a lot of effort involved when maintaining a fork of something as complex as LLVM and, in the long term, that it's easier adapting your niche to XYZ than it is to fork XYZ and adapt that fork to your niche; that eventually your XYZ fork becomes XWV because you're now so backwards from upstream. There's a reason why open source is winning in the long run and that's basically why.
    maybe this would be an option for AOCC don't know why they don't change the march=znverXY branches to their AMD likes.

    Leave a comment:

Working...
X