Can't compile on Fedora about compute-runtime HOT 16 CLOSED

Hi @myownfriend could you share entire build log?

from compute-runtime.

Here's logs for both methods I tried.

cmake.gz
rpmbuild.gz

from compute-runtime.

1. could you try to build the latest release?
2. I see it is using GCC 14, could you try with other compiler version?

-- The C compiler identification is GNU 14.0.1
-- The CXX compiler identification is GNU 14.0.1

from compute-runtime.

I tried compiling the latest release on the same thing happened but that's with GCC 14.0.1. In the morning I'll try GCC 13 but technically when I first tried compiling it I was on Fedora 39 which ships with 13.2 and it didn't work then either so I don't think that's the issue.

from compute-runtime.

(Disclaimer: I'm not a compute-runtime developer, just another user.)

I just got an A770 and I'm trying to get Davinci Resolve to work so I'm trying to compile master. I've used the provided instructions in build.md to try to just build it and I've tried building it with rpmbuild using the official Fedora intel-compute-runtime RPMs as reference.

What's the problem when using the official Fedora RPMs?

And why you're trying master instead of a tagged (tested) version?

(AFAIK only reason to use master would be testing experimental Xe KMD.)

When compiling normally I'd start to get "may be used uninitialized" warnings once it gets to "compute-runtime/shared/source/os_interface/linux/drm_memory_manager.cpp" and before it ends with

Newer compilers enable new warnings => While those warnings may be relevant, it's better to disable all warnings being treated as errors build option when using new compiler, unless you're planning on contributing fixes to the warnings.

I think there's some testing for GCC 13, but a better tested compiler combo for compute-runtime should be something like GCC 11 + LLVM 14 (compute-runtime build uses both GCC & LLVM).

Note that because LLVM ABI is not stable, things will NOT work properly if components built with different LLVM versions (e.g. distro ones, and ones you build yourself) get linked together!

If I compile locally then memory usage balloons to 70 GB and then my computer crashes.
...
I'm on Fedora 40 but I've also tried it on Fedora 39.

Memory usage of the compiler balloons to 70GB? => Sounds like a potential compiler bug you should report to your distro bug tracker...

from compute-runtime.

What's the problem when using the official Fedora RPMs?

And why you're trying master instead of a tagged (tested) version?

(AFAIK only reason to use master would be testing experimental Xe KMD.)

With the version that ships with Fedora 40 (23.35.27191.9), I can get into Resolve, the card will be recognized, and I can drop clips onto the timeline but nothing has a preview and nothing can be played back. After looking up the issue I found out that it's because Resolve needs CL/GL sharing patches that smunaut contributed. They specifically wrote those patches to get Resolve working in Intel hardware and they were only merged about 2 weeks ago.

When compiling normally I'd start to get "may be used uninitialized" warnings once it gets to "compute-runtime/shared/source/os_interface/linux/drm_memory_manager.cpp" and before it ends with

Newer compilers enable new warnings => While those warnings may be relevant, it's better to disable all warnings being treated as errors build option when using new compiler, unless you're planning on contributing fixes to the warnings.

I think there's some testing for GCC 13, but a better tested compiler combo for compute-runtime should be something like GCC 11 + LLVM 14 (compute-runtime build uses both GCC & LLVM).

Note that because LLVM ABI is not stable, things will NOT work properly if components built with different LLVM versions (e.g. distro ones, and ones you build yourself) get linked together!

Memory usage of the compiler balloons to 70GB? => Sounds like a potential compiler bug you should report to your distro bug tracker...

I'll definitely report it to them then. What I don't get is how there is an official intel-compute-runtime for Fedora 39 and 40 at all if the compiler is having issues with the compiler.

There are source RPMs that people made that just take the official Fedora RPM and just add the patches for CL/GL Sharing and those don't compile either.. In fact even without those patches, I can't get the the official RPMs to rebuild from source.

from compute-runtime.

What I don't get is how there is an official intel-compute-runtime for Fedora 39 and 40 at all if the compiler is having issues with the compiler.

Links to official builds can be found from here: https://src.fedoraproject.org/rpms/intel-compute-runtime

And build logs both for Fedora 39 & 40 show them being done with GCC 13: https://kojipkgs.fedoraproject.org//packages/intel-compute-runtime/23.35.27191.9/1.fc40/data/logs/x86_64/build.log

Do those look very different from your build output?

PS. Are you building just compute-runtime or the whole compute stack (gmmlib, vc-intrinsics, spirv stuff, IGC etc)?

from compute-runtime.

Links to official builds can be found from here: https://src.fedoraproject.org/rpms/intel-compute-runtime

And build logs both for Fedora 39 & 40 show them being done with GCC 13: https://kojipkgs.fedoraproject.org//packages/intel-compute-runtime/23.35.27191.9/1.fc40/data/logs/x86_64/build.log

Do those look very different from your build output?

Yup. Obviously there's the difference in compiler and pkg-config versions but I'm also seeing additional flags being set in the Fedora build:

Werror=implicit-function-declaration -Werror=implicit-int

Other than that, I didn't see anything that, I didn't see anything that stuck out.

PS. Are you building just compute-runtime or the whole compute stack (gmmlib, vc-intrinsics, spirv stuff, IGC etc)?

Just the compute-runtime. Shouldn't that be fine though?

from compute-runtime.

PS. Are you building just compute-runtime or the whole compute stack (gmmlib, vc-intrinsics, spirv stuff, IGC etc)?

Just the compute-runtime. Shouldn't that be fine though?

If you would have been building also the others, that could have explained rpmbuild issues. They looked like the ones I get when some component in the stack had been built with a different LLVM version, as LLVM breaks its ABI between versions (which is a large headache for compute stack due to distros updating their LLVM version regularly: https://github.com/intel/intel-graphics-compiler/projects/5).

@frantisekz Would you have some idea why @myownfriend's builds of Fedora's compute-runtime RPMs fails:

There are source RPMs that people made that just take the official Fedora RPM and just add the patches for CL/GL Sharing and those don't compile either.. In fact even without those patches, I can't get the the official RPMs to rebuild from source.

from compute-runtime.

@myownfriend could you please compile with cmake with additional flag -DNEO_DISABLE_LTO=0?

from compute-runtime.

@myownfriend could you please compile with cmake with additional flag -DNEO_DISABLE_LTO=0?

Looks like the exact same thing is happening.

from compute-runtime.

sorry, -DNEO_DISABLE_LTO=1

The flag is set to 0 by default

from compute-runtime.

sorry, -DNEO_DISABLE_LTO=1

The flag is set to 0 by default

lol I figured that was probably the case. Tried that and the same thing happened.

from compute-runtime.

@frantisekz Would you have some idea why @myownfriend's builds of Fedora's compute-runtime RPMs fails:

I can take a deeper look, but I am planning to rebase both igc and compute-runtime in Fedora this week (including backport of CL/GL improvements on top of the latest 24.09 tag). I have working builds and changes locally.

Subprocess killed could mean too much of a RAM pressure if I had to guess, but it's also important to have an updated igc in the buildchroot too (it can crash/fail otherwise while building the compute-runtime builtins).

from compute-runtime.

@frantisekz Would you have some idea why @myownfriend's builds of Fedora's compute-runtime RPMs fails:

I can take a deeper look, but I am planning to rebase both igc and compute-runtime in Fedora this week (including backport of CL/GL improvements on top of the latest 24.09 tag). I have working builds and changes locally.

I'm really glad to hear this!

Subprocess killed could mean too much of a RAM pressure if I had to guess, but it's also important to have an updated igc in the buildchroot too (it can crash/fail otherwise while building the compute-runtime builtins).

I'm gonna try that in the meantime

from compute-runtime.

@frantisekz Would you have some idea why @myownfriend's builds of Fedora's compute-runtime RPMs fails:

I can take a deeper look, but I am planning to rebase both igc and compute-runtime in Fedora this week (including backport of CL/GL improvements on top of the latest 24.09 tag). I have working builds and changes locally.

Thank you! I just got the new RPM when I updated Fedora and now it works. Unfortunately it doesn't completely fix Davinci Resolve. There was progress at least! Previews show up but the media pool but they're small and tiled in the timeline viewer. That's unrelated to this topic though.

from compute-runtime.