Announcement

Collapse
No announcement yet.

Artem Tashkinov: Independent Hardware Vendors Hate Linux

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

  • Originally posted by pal666 View Post
    well, it is hard to have sophisticated discussion with people living in alternate reality where linux does not have best hardware support among all operating systems for more than a decade
    Best legacy support, yes. When it comes to present hardware of the common user base, I disagree.

    Comment


    • As a user/application developer (I am one of the implementors on the BRL-CAD OpenCL support) I can note several problems on why OpenCL isn't supported more. Closed source applications (e.g. games or utilities) on Microsoft Windows do not use it much historically because it did not allow source code compilation into binaries for code obfuscation purposes. This has only been fixed with compilation in LLVM IR code in OpenCL 2.0. But LLVM IR caused a lot of headaches for the OpenCL driver developers, because the LLVM API is a moving target, so these implementations could not be supported in the long run. Hence SPIR-V. This has only been fixed in OpenCL 2.1.

      Also, because we did not have source code compilation into cross-platform binaries, this means that library support for OpenCL is typically crap compared to, say, CUDA. OpenCL application developers are typically forced to write applications basically from scratch which makes application development cumbersome. We need SPIR-V.

      As an application developer and user there are plenty of advantages in OpenCL vs CUDA. The major one is that the same code can run on both GPUs and multi-core CPUs with vector support and take full advantage of the hardware. The major issue OpenCL has, currently, is lack of uniformity of support across vendor versions. Presently we develop with OpenCL 1.2 because that's the lowest common denominator among implementations.

      Why is support for OpenCL versions over 1.2 so bad? The vendors should IMHO be aiming for OpenCL with SPIR-V support. I have my own views on this. I think problem is OpenCL 2.1 introduces C++ support. That probably complicated the drivers and libraries tremendously and made the implementation and validation a headache. Given the lack of applications this creates a chicken and egg problem for development. I believe that is the main reason why OpenCL 2.1 support has been stalled tremendously. The other issue is some of the OpenCL 2.0 features like nested parallelism likely aren't easily hardware portable. Also, the shared virtual memory is reliant on hardware support as well. These should likely be an extension rather than being part of the basic spec.

      I think we need an OpenCL 1.4 which is basically OpenCL 1.2 with some 2.x features (e.g. C11 atomics), SPIR-V, Android installable, which can be easily supported across hardware with minimum vendor work. This would ease the transition to 2.x which should become easier once OpenCL C++ support gets more integrated into clang/LLVM.

      In addition, the presenter said Clover has poor image support. Well I think image support should just be dropped from the OpenCL spec and made into an extension. OpenCL images are useless crap! Most OpenCL versions do not support texture arrays, and I think none of them support mipmaps. This makes the texture support totally useless! We are better off using plain old 2D byte arrays as application users. Seriously. It's that bad. Hopefully this will get fixed when CLnext comes out.

      Regarding the status of OpenCL vendor implementations: we use the AMD, NVIDIA, and Intel implementations. NVIDIA still only supports OpenCL 1.2 (although there is some basic 2.0 in there). Intel does not make a gaming oriented PCIe GPU card (let's ignore things like Xeon Phi that no one uses) and on-chip GPUs are pathetically slow which means only the OpenCL CPU support is widely useful.

      I think you guys should aim for the coin miner applications as a target market to support with OpenCL as the initial application target set.

      The guy who developed the presentation seemed awfully defeatist to me. He also seems to think OpenCL Next will solve the problems. It won't. And don't wait for it! We application developers don't need the full 2.x spec in the near future! By the time OpenCL Next comes out, you could have implemented half the 2.x spec and much of it will likely be reusable for OpenCL Next.

      I have a plan on how to merge the disparate open source implementations in case someone's interested.

      Comment

      Working...
      X