LLVM's libclc Adds Mesa SPIR-V Target

[airlied]

Wow, that's great. I'll experiment with it soon! Which component is in charge of this? For example Ubuntu provides libclc-amdgcn, libclc-r600, libclc-ptx, but none of them seem to be related to nouveau.

Is there more variables for undisclosed hardware? on AMD side TeraScale 1 hardware was OpenCL 1.1 capable if I'm right but libclc-r600 seems to only support TeraScale 2 and greater.

Is this variable specific to clinfo or to some Mesa component loaded by clinfo? Because as an example, if on Ubuntu I install libclc, ROCm and AMDGPU-pro OpenCL, I end with three clinfo binaries that do not read the same environment variables to do the same things… Does NOUVEAU_ENABLE_CL work every time regardless of clinfo binary?

It's currently a bit messy to get setup, You have to build llvm/clang for clover to work, and have the SPIRV-LLVM-Translator installed built against the llvm/clang build you are using.

For some functionality you need the patches mentioned here to add spirv-mesa3d- and spirv64-mesa3d- to liblcc.

none of this is packaged yet, it's under active development.

Dave.

[illwieckz]

It's currently a bit messy to get setup, […] none of this is packaged yet, it's under active development.

I see, thanks for the answer, I'll see If I can add it to my OpenCL testbed.

[tildearrow]

In this case, Michael's right. In LLVM, the targets started out as just R600 and eventually it was renamed to the AMDGPU target. There are both R600 and AMDGCN subtargets within.

The problem is, he didn't write GCN. He wrote "GN".

[pmoreau]

Is there more variables for undisclosed hardware? on AMD side TeraScale 1 hardware was OpenCL 1.1 capable if I'm right but libclc-r600 seems to only support TeraScale 2 and greater.

There are no additional environment variables for Nouveau. Note that this will currently only work for Fermi and higher; work is underway for also supporting Tesla but the missing bits have not been upstreamed yet as not quite ready (though you can still get basic OpenCL kernels running).

Is this variable specific to clinfo or to some Mesa component loaded by clinfo? Because as an example, if on Ubuntu I install libclc, ROCm and AMDGPU-pro OpenCL, I end with three clinfo binaries that do not read the same environment variables to do the same things… Does NOUVEAU_ENABLE_CL work every time regardless of clinfo binary?

You need to set `NOUVEAU_ENABLE_CL` anytime you want to use OpenCL, regardless of the program, as otherwise Nouveau will not advertise OpenCL support.

[pal666]

It seems you don't know what you talk about but you believe you do

were you talking in front of mirror?

[illwieckz]

were you talking in front of mirror?

Stop polluting this thread. There is a difference between missing knowledge about a work-in-progress unreleased effort requiring special tricks to be used because it's disabled by default and known to be “messy to setup” and thinking throwing the “nouveau” word as a magical incantation would answer the questions of someone that clearly knows topic more than you. You even don't know enough the topic to notice Michael has given the answer I was looking for and that your answer had less knowledge but still you thought it was useful to add it. This is called Dunning–Kruger effect.

I already warned you on AMD compute side recently, you were contradicting someone saying compute on AMD side “seems to be plagued with for 1-2 years” with the impressive argument of you “don't use compute”. You really said you “don't use compute”, you really said you were “not aware of any issues” while not using compute and you really used that argument to denial the fact people using compute may face problems people not using compute would never face.

You clearly don't know this topic. The simple fact you act like it would be enough to throw the “nouveau” name to fulfill a need when it's not released, not easy to install, not enabled by default, not conformant shows you overestimate your knowledge. And the simple fact you act like the “nouveau” name would be unknown shows you underestimate others' knowledge. You clearly failed to identify what was the knowledge I missed. You lacked the knowledge to identify which knowledge I missed.

[illwieckz]

Thanks pmoreau for your answers. There is a real need for a “working group” or a “task force” to team-up on making OpenCL better on Linux. Today it's a minefield. Knowledge is hard to reach and setup is not easy.

But things are there:

• there is two Intel OpenCL Frameworks for linux, an Open Source one (Beignet) and a proprietary Intel SDK;
• there is three (four ? five ?) AMD OpenCL implementations: open libclc, proprietary AMDGPU-pro (Legacy), open ROCm, with AMDGPU-pro (Legacy) having the widest GPU support and (on older versions) support for amd64 compatible CPU (either Intel or AMD);
• then this upcoming libclc work for nouveau and the proprietary Nvidia blob for Nvidia GPU;
• and on CPU side there is pocl (that has work-in-progress proprietary-nvidia-based GPU backend and HSA-based AMD GPU backend);
• etc.

And no one knows how to install and use them… Some OpenCL frameworks may be faster than others on the same task and same hardware, somes may not be complete enough for a given task while others do…

Since months I plan to open a place for people to meet together to gather knowledge on OpenCL on Linux.
I just created a repository on my GitLab as a draft for a working group:

• https://gitlab.com/illwieckz/i-love-compute/#i-compute

I dumped some knowledge I had in my head in a markdown file, but in the end, it would be good to have a dedicated wiki, repository for scripts, maybe a place to talk, etc.

There is working OpenCL on linux for all GPU brands, with plenty of competing frameworks. I would be surprised to find someone not being able to do something he wants with any of those frameworks. The problem is that nobody knows™.

[Veerappan]

The problem is, he didn't write GCN. He wrote "GN".

Whoops. Yeah, that's me mis-reading your quoted part of the article.