Vcc Announced As The Vulkan Clang Compiler

[phoronix]

Phoronix: Vcc Announced As The Vulkan Clang Compiler

Coming out of Saarland University is Vcc, the Vulkan Clang Compiler. Vcc provides an "honest attempt to bring the entire C/C++ language family to Vulkan" as an interesting new compiler...

https://www.phoronix.com/news/Vcc-Vulkan-Clang-Compiler

[dimko]

Vulan GPU vs CPU, LETS GET IT ON!

[Gobrosse]

Hi Michael, thanks for sharing the story !

One thing I forgot to put front and center on the website is the fact that I will be talking about Vcc at Vulkanised 2024 on Feb. 7 https://vulkan.org/events/vulkanised-2024#agenda, could you amend the article to mention that ?

Thanks

[ddriver]

Ruby or gtfo

[skeevy420]

Between travel, lodging, and the event fee it'd cost Michael, or anyone else for that matter, around $1200 to do some in-person reporting, interviews, photography, and video which makes me wonder if they have a press passes for places like Phoronix or Gaming On Linux.

I wonder things like that whenever I read about various conferences here on Phoronix, especially when the media in the article consists of a beer sitting on a server.

[coder]

I will be talking about Vcc at Vulkanised 2024 on Feb. 7 https://vulkan.org/events/vulkanised-2024#agenda, could you amend the article to mention that ?

Hello. Very interesting work.

Have you prepared any like-for-like performance comparisons vs. GLSL? I wonder just how much performance one might be leaving on the table, by embracing Vcc. I assume they're targeted at different use cases, but it'd be interesting if we could also use vcc to write normal graphics shaders.

[S.Pam]

I am curious if we will be able to run normal cpu programs on the gpus when compiled through stuff like this. Some apps would definitely benefit from fast memory and dedicated compute units.

I'd imagine that high compression ratio algorithms could benefit since gpus have massively fast memory, which is needed to parse lots of data. I.ee 7zip with large block size compared to the small blocksize of zlib and bzip2.

Also apparently something like it exists already, albeit a cuda only thing. https://developer.nvidia.com/nvcomp

[jhuber]

I am curious if we will be able to run normal cpu programs on the gpus when compiled through stuff like this. Some apps would definitely benefit from fast memory and dedicated compute units.

There are existing implementations of this. The work in this paper (https://tianshilei.me/wp-content/upl...lvm-hpc-22.pdf) compiled CPU OpenMP programs to run on the GPU automatically and passed most of the LLVM suite. There is also a project in LLVM to build a GPU implementation of libc (https://libc.llvm.org/gpu/). The test suite for that project simply treats the GPU as a hosted target via cross-compilation (I.e. there is no concept of host and device) and runs a gtest-like suite on that source. And example of the test suite output is here (https://lab.llvm.org/staging/#/build.../10/logs/stdio).

The current way Clang handles this is cross-compilation via the `--target=` flag. Beyond that it's primarily a question of which magic builtin function calls to use when targeting the hardware. Here's an example, https://godbolt.org/z/Taq5sM5s8. Right now this only works for LLVM-IR targets, but my understanding is that soon a SPIR-V target will work as well, Intel seems to be working on it.

[dev_null]

and it’s already a time when GPUs should be mounted to a system block case, and have a slot for motherboards

[linuxgeex]

and it’s already a time when GPUs should be mounted to a system block case, and have a slot for motherboards

Think you mean CPU daughterboards lol. GPUs have bus mastering but not bus arbitration, so they can't literally do that yet... but I get what you mean.

Using an octopus as a parody, the PCIe bus being the nervous system, the GPU really is the main brain as far as total compute and bandwidth are concerned. The CPU and other peripherals being the arms with their own nervous systems working in parallel. But back to arbitration... an octopus doesn't have one arm (CPU) deciding what the others do.

The GPU likes to play but it needs to accept more responsibility ;-)