@joebonrichie @GZGavinZhao You guys are amazing! Thank you so much for fixing it so quickly, while I was sleeping ;) And yes, rocm-opencl works just fine, and I can build rocBLAS with rocm-hip, so this seems to be working just fine too. Thanks for your amazing job!

In D13464#232092, @algent wrote:

In D13464#230688, @Jacek wrote:

They changed the config file location, so users will need to manually move them, or configure it again. I don't see an easy way to patch it.

Moving files from /etc to /usr/share will be reported by eopkg as a broken package.

In D13126#231434, @joebonrichie wrote:

Built this locally the other day and found out solbuild supports file:// URIs no problem. e.g. file:///home/foo/solus/dart/dartlang-2.17.6.tar.zst

Nobara integrates this and a better vaapi support into the main package, maybe we could do the same?

They changed the config file location, so users will need to manually move them, or configure it again. I don't see an easy way to patch it.

Remove one argument that is no longer needed

I think what could be the problem for you is this: https://github.com/intel/intel-vaapi-driver/issues/533
With a Mesa update your GPU is no longer using the old Intel driver, but Crocus - new Intel driver adapted for old GPUs. And the libva-intel-driver version we have in the repos doesn't include support for it.
So either you could maybe try the workaround they posted, or someone could patch the driver with that one commit.

Unfortunately you GPU is super old and no longer supported by intel-media-driver https://github.com/intel/media-driver#supported-platforms
Here they suggested using intel-vaapi-driver instead.
Could you install libva-intel-driver and try again?

Could you post here your system specs? It is working fine on both my old Intel (Broadwell) and AMD system.

Have you tried manual partitioning? I found once I manually created /, swap and boot partitions like in the helpcenter docs, rebooted, it detected the new partition nicely.
https://getsol.us/articles/installation/disks/en/

In D13172#228658, @joebonrichie wrote:

Can you update the test plan? Either with an application or you could consider converting this cuda sample to hip for example https://github.com/ROCm-Developer-Tools/HIP/tree/develop/samples/0_Intro/square

Remove unnecessary textfiles

So I think when it can't mach the set of characters it must be falling back to some other driver, maybe LLVMPipe? So clearly Intel video drivers, both for new GPUs and the old ones are the problem. Could any of you report that on Gnome callendar's bug tracker, or maybe even Mesa bugtracker?

Well, the solution is to build i915 again for now on Solus side, and report this issue upstream, on Mesa or gnome calendar bugtracker.

Don't specify for which architecture to build

Remove specifying for which architectures to build, seems to not be necessary

Funny, ZIG has just fixed compatibility with LLVM 14... Only thing needed would be to backport those patches.

@moriel5 If you want to see something like a Budgie Calendar, you would need to report it at Budgie's bugtracker, not here.
Also, they did run sudo eopkg check already, this problem is not due to broken packages. But it really is weird that on your Intel machine it is working.
Could it be that on newer Intel graphics using "Iris" driver (Broadwell 5th-gen and up) it works, but this bug only concerns the old i915 driver? Maybe Mesa update to 22.0.5 fixed it for newer processors but not the older? If that is true, then switching to "Crocus" driver on older processors would fix it, as it uses newer driver code.

I have updated all of it to 5.1.3, which is the newest version we can use with LLVM 14, and 5.2 doesn't build with it and will probably require LLVM 15.
After the changes I made to rocm-hip and finally managing to build a package depending on it I am confident in the whole stack and I hope it can land once LLVM gets updated to 14, and solbuild gets updated to latest git.

Update to 5.1.3, remove use of __noinline__ which broke compatibility with newer GCC

Update to 5.1.3

Update to 5.1.3

Update to 5.1.3

Update to 5.1.3

Update to 5.1.3

Update to 5.1.3

@DataDrake Then probably this can be closed now, if you think LSI should keep going how it is, and this topic can be reassessed if anything changes in the future?

Make hip build use static rocclr
This means I have to include all the patches and sources of -opencl, but there is no other way until upstream changes its approach

Remove the patches allowing to split rocclr into separate package
Unfortunately it means that the hip build will have to contain all the sources of -opencl, and all the patches, but standalone build was abandoned by AMD employee maintaining for Fedora, so better roll back too.

It is also useful to do sudo eopkg check when an app fails, and do sudo eopkg it --reinstall {appname} if any shows up as broken.

I think the main problem is that there are 2 blacklists now. One done by Valve, where they learn about problems first, and then one in LSI, where we only learn it when someone runs into an issue.
So I think all we could do is find where that blacklist is in https://gitlab.steamos.cloud/steamrt/steam-runtime-tools and monitor it. Then it would be much easier to troubleshoot and understand what Valve is trying to do. And then LSI can live on.
I think the blacklist here, separate depending on which runtime a game is using (scout, soldier or in the future sniper): https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/master/tests/pressure-vessel/inside-runtime.py#L691 and https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/master/tests/pressure-vessel/containers.py#L937

Also, on Discord's Github it seems they finally started work on using newer Electron version, so hopefully they will update it in their client soon, and it might fix some of the issues.

In D13162#227617, @GZGavinZhao wrote:

Oh nevermind I'm using LLVM 13. That's very dumb of me...

I think you should mention fslint in the description or summary, so people looking for fslint find this alternative.

Adopt patches from Debian to unbork .cmake files even more

The fix has now been merged into Steam Runtime. This can now be closed.

The pull request fixing intel-graphics-compiler on LLVM 14 has just been merged. So that can probably be changed to OK

Could you see if it crashes when you are using speakers instead of this USB headset?

Could you give more info? Are you using Bluetooth? Did you move to experimental pipewire? Probably not a problem, but what GPU do you have? Are you fully updated?

Change ROCM_DIR to ROCM_PATH

Add rocminfo as a rundep

Add numactl as builddep, one more patch, and one more argument to fix a warning

Add rocm-cmake to get rid of a warning

Add rocm-cmake to get rid of one warning

Update patches for LLVM 14 and add rocm-cmake

Make hip-config.cmake less broken, allowing to build stuff that relies on hip

I might try to maintain intel-compute-runtime for a while, until the desktop GPUs come out. Maybe then someone will take it up, or I get one.
For now I only have a Broadwell 2in1 to test it on, which is last supported generation.

@Girtablulu Before this can be built, https://github.com/getsolus/ypkg/pull/29 and https://github.com/getsolus/solbuild/pull/22 need to be accepted.

While trying to fix T10265 I managed to fix the overlay at least with the native runtime disabled. But it would need some testing if it doesn't cause any issues.
And as for native runtime enabled, still my only idea is this, which is less than ideal.
Edit: I feel so dumb... it has always worked with with native runtime enabled. So, the fix above should fix this issue fully!

You can verify LD_PRELOAD by opening htop, finding your game (which crashes, so you can check steam instead for example), and press 'e'. It will show all environment variables for this app. But I have checked for my PC, and with this patch it is not creating an LD_PRELOAD. So maybe your Dota 2 issue has a different source?
If it is still crashing even without /usr/$LIB/libstdc++.so.6 in LD_PRELOAD, maybe you can report that back on Steam bugtracker, and you can look for a different cause? Because this seems not to be it?

Oh, it still didn't fix your issue? The patch I made removed the LD_PRELOAD, it did fix another issue with overlay, hoped it would fix yours too.
Maybe try to install the .eopkg I created? And turn off Native Runtime in LSI settings. After you finish testing you can do sudo eopkg it linux-steam-integration --reinstall to go back to system version.

Yup, this fixed it! Now everything just works with native runtime disabled, overlay loads just fine, no problems with Mesa.
https://github.com/JacekJagosz/linux-steam-integration/commit/f80c5743702f2de8ff9f59c9e8866b98aec4f0ec

@joebonrichie I tested both removing them from vendor_blacklist and meson_options.txt, didn't cause any problems. But also didn't fix the overlay, which is weird
But that is not what I mean. I don't want to change anything when Native Runtime is enabled. So I don't want to touch those global settings.
I just want to disable adding of LD_PRELOAD when Native Runtime is disabled.
I think this should only happen when the Native Runtime is enabled.

Basically, the default path is LD_PRELOAD=/usr/$LIB/libxcb.so.1:/usr/$LIB/libX11.so.6:/usr/$LIB/libstdc++.so.6:/home/jacek/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:/home/jacek/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so:libMangoHud.so, and the gameoverlayrenderer.so needs to be at the beginning (presumably before libstdc++?).
I guess this can be fixed in LSI in the order it sets up LD_PRELOAD?
Edit: I have created a fix. It does make the overlay work, but this causes a ton of errors on the terminal, as it tries to load the overlay for every single game process, not just the game.

I reported it on Steam's Github, and they did provide an insightful response. Could someone investigate it the way they suggested? https://github.com/ValveSoftware/steam-for-linux/issues/8594

If noone has another idea how to fix it, could /usr/lib32/haswell/libc.so.6 get removed from the package for now? This would unbreak all Steam games for all LSI users, and very little programs use the 32 bit library anyways, Steam is definitely the biggest one.

Remove builddeps no longer needed after moving to standalone ROCclr

Add rocm-compilersupport as rundep

In my opinion now the build is done, it should already be working with Vega, and is only waiting for LLVM 14 for full GPU support. I have tested it with new LLVM, it builds fine, so should be ready.
Edit: ypkg and solbuild pull requests allowing for renaming of sources need to be accepted too