From memory you have a RX550 (Lexa/Polaris12) which is the GCN 4th generation card, Leap 15.0 Mesa version supports openGL 4.5, vulkan version 1.0 is there also.
Radeon 500 series - Wikipedia
I have GCN 3rd generation cards (dual AMD gpu) which works fine running vulkan, openGL on Tumbleweed, I would expect your GPU to work fine on Leap…
Running the oss amdgpu driver will give far more support options via bug reports etc, there will be zero upstream support unless you switch to SLE 15 (You can get a free one year developer subscription).
Right… the RX550 is supported by amdgpu-pro… I don’t have dollars/eur to buy GPU for learning opengl/vulkan.
In the other hand, I tried many times with the “package” received from the “standard” amdgpu to obtain same behaviour with the examples given, it compiles but I have to set to 330 concerning glsl… and some shaders/fragments are
not compiled without modifying “types and nature” of those vertex/uniforms in the sharders/fragments description/code that sucks I did it since I upgraded from 13.2 to 42.3 and then since my R7-370 died.
This is not REALLY enoying to throw away amdgpu-pro but I’m happy to follow the courses without having to edit each source code or shaders ^^
Something strange: where I was crying because sometimes I had to reboot X times (where X is completly random from 1 to 6) to have the system booted BEFORE the update, here
when I select the kernel at grub2’s menu it boots each time correctly and as fast as before I changed amdgpu to amdgpu-pro with nfs and smb services available with no errors as I complained since two years now, I think (???)
Since my last message I booted a certain number of times my computer (that is not really a server because it doesn’t “work” 24/7) and I NEVER got the behaviours I complained for in different posts (???)
Here is the best record I never had before:
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @9.669s
└─multi-user.target @9.669s
└─smb.service @9.177s +491ms
└─nmb.service @2.986s +6.188s
└─network.target @2.976s
└─NetworkManager.service @2.607s +368ms
└─dbus.service @2.560s
└─basic.target @2.549s
└─paths.target @2.549s
└─btrfsmaintenance-refresh.path @2.549s
└─sysinit.target @2.532s
└─systemd-update-utmp.service @2.526s +5ms
└─auditd.service @2.485s +40ms
└─systemd-tmpfiles-setup.service @2.456s +25ms
└─local-fs.target @2.447s
└─run-user-0-gvfs.mount @35.084s
└─run-user-0.mount @14.600s
└─local-fs-pre.target @1.039s
└─lvm2-monitor.service @277ms +762ms
└─lvm2-lvmetad.service @302ms
└─lvm2-lvmetad.socket @275ms
└─-.mount
└─system.slice
└─-.slice
10 seconds to get on my desktop !!!
The kernel is the 10-67 with initrd modified by the **dkms-2.3-lp150.2.4.noarch.rpm **package installed (it creates a initrd taking in account the amdgpu-pro stacks I think).
I have NO IDEA to say why, when I modify the default kernel in grub this kernel (the same indeed) leads to a “random system” that needs sometimes 1 to 6 reboots to have the system ready to work on…
This works perfect when launched trough the grub menu… when I select it specificly.