So no mention of syCL support... Only offering ~C in 2020 is an insult to computer science.
Unrelated: when will Nvidia allow to seamlessly offload Java or another GC based language to the GPU?
https://developer.nvidia.com/blog/grcuda-a-polyglot-language...
GrCuda seems promising but it would only allow interoperability with Java on the CPU, not offload Java to the GPU, right?
Such advances would make gpu computing order of magnitudes more developper friendly and therefore much more mainstream.
Xilinx makes FPGAs, not GPUs. The advantage of an FPGA is that all operations take place at the same time in hardware.
Verilog is one language that I would expect strong support for... they do mention RTL, which does many of the same things.
This is not a general purpose programming environment, it is more of an data flow / filtering system.
There is no allocation of memory, thus no need for garbage collection.
Verilog, VHDL, and SystemVerilog are supported by Vivado. A small subset of C++ is supported through Vivado's high level synthesis compiler, which transforms some C++ code into Verilog. RTL stands for register-transfer level, which is a general layer of abstraction; one uses a hardware description language such as Verilog to describe RTL designs. The analogy of Verilog with RTL is "Verilog is to RTL, as Haskell is to functional programming".
If AMD can get their act together by seamlessly integrating their GPU, FPGA and CPU with minimum I/O bottleneck it will be a huge boon for the computing industry. People will start doing something that probably unthinkable now but will be very obvious in the near future. Personally I have one application in need of the proper integration of their disparate systems and already started talking to their R&D engineers but see little improvement being implemented.
FYI, AMD has come up with SSD storage and GPU integration before but with limited success [1], but if they can also integrate FPGA together that can probably be a recipe for a great success.
I think AMD and Intel (since they both own GPU/CPU/FPGA technology) really need to come up with open and intuitive design tools for these new systems or just sponsor the work on MLIR and LLHD by LLVM and ETH Zurich, respectively.
FPGA vendor support for higher-level synthesis tools is still pretty poor. Not surprised on that front.
Offload-from-GC runtime tools do exist, e.x. Cudafy would translate .Net code into Cuda kernels and handle kernel dispatch. Of course, you were very limited in what constructs and types you could put in kernel functions, but you could write your whole application in C# and accelerate the important blocks.
In practice, a lot of beginner GPU computing has moved to the world of NN training and inference, in which the complexities of GPU offload are entirely wrapped by the libraries you use.
For traditional GPU-accelerated tasks, the limited languages available are not the problem. Decomposing your problem into a form that is amenable to GPU offload can be difficult, and if you're experienced enough to do that well, writing Cuda kernels and dispatch in C++ is not an obstacle. For example, Cudafy meant you didn't need to know Cuda-specific syntax and expressions, but you still had to understand the behavior and limitations of GPUs to write performant code.
Unrelated: when will Nvidia allow to seamlessly offload Java or another GC based language to the GPU? https://developer.nvidia.com/blog/grcuda-a-polyglot-language... GrCuda seems promising but it would only allow interoperability with Java on the CPU, not offload Java to the GPU, right? Such advances would make gpu computing order of magnitudes more developper friendly and therefore much more mainstream.