[Info-vax] Some of what I'm reading...

[Stephen Hoffman]

On 2019-07-01 02:05:49 +0000, Scott Dorsey said:

> IanD  <iloveopenvms at gmail.com> wrote:
>> The take away for me is that gpus cannot be ignored going forward, they 
>> are pivotal in anything machine learning related and applications 
>> lacking a ma= chine learning component are starting to look a little 
>> tired, especially as= we move into stream based learning models and 
>> workloads. Now SQL execution may start levering them
> 
> The problem here is that much of the internals on the GPUs are either 
> undocumented or poorly documented, so you need to be using the 
> GPU-vendor-provided programming environment and libraries and 
> duplicating that environment is difficult.

I'll take that in reverse...  Programming environments, and then 
graphics hardware documentation...

Related APIs here include NVIDIA CUDA for NVIDIA hardware, and Vulkan. 
Among others.  Among the others, OpenCL is merging into Vulkan, though 
it's still in wide use. OpenGL—which OpenVMS has had some support 
for—is also being replaced by Vulkan.
https://01.org/compute-runtime
https://www.khronos.org/files/vulkan11-reference-guide.pdf

There's support for both CUDA and OpenCL in clang.

https://www.llvm.org/docs/CompileCudaWithLLVM.html
https://github.com/intel/opencl-clang

If you're interested in OpenCL and related computing topics, and with a 
side-helping of why minimum password lengths are necessarily getting 
longer, and why weak hashes are a problem, there's always hashcat:
https://hashcat.net/hashcat/

ATI AMD has piles of doc available, too:
https://gpuopen.com/professional-compute/

OpenCL isn't too bad to use, based on some experimentation with macOS 
(just) prior to the OpenCL deprecation in macOS Mojave 10.14 and the 
advent of Apple Metal.  Clang and OpenCL allow embedding the GPGPU code 
right in the main application source, and OpenCL takes care of 
compiling that into SPIR-V and invoking it on the target hardware.
https://developer.apple.com/opencl/
https://github.com/KhronosGroup/MoltenVK

If you're doing a lot of same-or-very-similar changes over big arrays 
of data and enough that you've gotten your apps CPU-bound—if you're not 
wedged behind I/O or memory—then offloading some of those calculations 
might help reduce run-time.

VSI has (many) other things on the schedule (well) ahead of adding 
support for Vulkan, but they're undoubtedly aware of OpenCL and Vulkan.

Now the use of Clang and the x86-64 support for Intel HD and Iris 
graphics that's all been discussed by VSI (eventually) means less work 
to add OpenCL and/or Vulkan support, though.  For whoever decides to 
add it.  The Intel graphics documentation is available too, which is 
handy for anybody that wants to try this with the embedded Intel 
graphics hardware.
https://01.org/linuxgraphics/documentation

And no, I wouldn't expect Intel or AMD or NVIDIA to be particularly 
working with VSI around graphics and compute support here, either.


-- 
Pure Personal Opinion | HoffmanLabs LLC