AMD Open Source Driver for Vulkan
phoronix.com
phoronix.com
I had AMD on my Linux boxes for eight years and I have haven't had an issue for the past six years.
Intel works quite fine. I'm pretty sure it's just nVidia that's the problem.
You had a problem with ATI's closed-source driver 14 years ago. AMD's open-source driver now is a COMPLETELY different story.
Indeed. In 2003 no-one would have based their expectations on what happened in 1989. 14 years is an eternity in this field.
Also GOOD NEWS ATI is dead, it wasn't AMD that manufactured the Card or the Drivers! It was a company called ATI based in Canada. https://en.wikipedia.org/wiki/ATI_Technologies
AMD bought them 2006 and killed ATI brand 3 years later. Also I bet you only a handful of people actually still work on the technology.
Read the offical documentation on Linux with SUSE and NVIDIA.
http://www.nvidia.com/object/linux_display_ia32_1.0-4363.htm...
Linux in 2003 is a totally different beast today. Tell me you got your wifi working or NVIDIA with a working desktop out of the box. I would sit in the terminal and have to install proprietary drivers just to see Gnome or KDE. I would have to sit by the Ethernet port for a while till I got wifi working.
Read this forum post I can post hundreds of these because I read them all trying to get my card to work. I had to edit my X11 configs by hand till around 2008???
https://www.opengl.org/discussion_boards/showthread.php/1575...
[1] https://www.phoronix.com/scan.php?page=article&item=16way-gp...
Now as for what I would need the compatibility profile, it is very simple: i just find it more convenient to use so i have a ton of code that uses it. The original idea for the separation of profiles was that the core profile would make implementing OpenGL easier and make it faster but neither of those actually happened (as i said, NVIDIA despite implementing the entirety of OpenGL is still the fastest implementation) while i really disagree with the idea of pushing the complex bits towards the end users (of the API) in order to avoid the implementors doing it. It is better to have 1 developer on the driver/implementation side handle the complexity that 1000 users (of the API) are going to enjoy than have each one of those 1000 users make 1000 individual solutions to that complexity, thus multiplying the time spent on the complexity by 1000 (this of course applies to all tech that by itself is "simple" only because it pushes the hard bits to its clients - see Wayland as another example).
Ok, so actually i have two reasons, one practical (i find it convenient) and one more ideological (pushing complexity upwards). Actually i have two ideological reasons, the second (and actually more important) is that i dislike backwards incompatible breakage in APIs and libraries (unless that API is meant for internal or utility use, of course, or is in beta/development stage). This is a much bigger issue though, so let's leave it at that :-P.
If you have a good understanding of how GPUs actually work (of which the OpenGL pipeline is just a very crude and simplistic abstraction), you can understand why modern APIs like Vulkan and DX12 are the way they are and also the power they hand to a capable user.
The hardware model underlying the design of OpenGL has aged. The one used for 1.0 and 1.1 is so outdated now that using it runs exactly counter to what the driver needs to do on hardware built within the last 15 years. The story gets a bit better once you get to vertex buffers, but those are not exposed in a way that lets the driver handle them without any guesswork on its part. The same is true for textures and framebuffers. Even that damned global OpenGL state is a quint relic of the past. Modern drivers should get the desired new state all at once instead of piecemeal through a chain of calls that triggers expensive recomputation of the desired actual GPU hardware state at each step.
Instead of clinging to OpenGL 1.x or 2.x for no good reason, you should really switch to a high level drawing library or rendering engine that knows how to pass things properly to an underlying modern API.
That is your opinion, mine is that breaking compatibility is the wrong answer in all but the most extreme cases (of which OpenGL was not).
Keep in mind however that i am talking about OpenGL. IMO they should have indeed created a more low level API similar to Vulkan back in 3.0, but instead of calling it OpenGL 3.0 they should have called it something else (like, i dunno, Vulkan :-P) and left OpenGL 3.0 alone to be an easy to use and fully backwards compatible API without creating an unnecessary schism (like the one we have with Apple/Mesa and everyone else today).
Of course that is what they eventually did with Vulkan, but i'd rather have that without the damage that they made to OpenGL.
> Instead of clinging to OpenGL 1.x or 2.x for no good reason
I have a good reason, i already explained it in my post.
> you should really switch to a high level drawing library or rendering engine
That library already exists and is called OpenGL with the compatibility profile. The only problem is that it isn't supported by every vendor that claims OpenGL support.
I just recently build a full AMD system (Ryzen 5, Radeon RX 560) and I couldn't be happier. I've had Intel systems that were fine but couldn't keep up with GPU performance. I've also had nvidia systems that were fine performance wise but the closed nvidia driver has been more and more problematic lately (crashes, VSync is off, etc.).
Not only that but it's all free software. When freesync support lands I can't image ever using anything but AMD under Linux.
I'm actually at the point where I need an upgrade for my work laptop, and I am going to seriously push for something that doesn't use NVidia graphics since they're such a pain to deal with under Linux (especially Optimus, holy crap).
CUDA is a registered trademark by NVIDIA - https://trademarks.justia.com/850/30/cuda-85030071.html
Here is the CUDA webpage
The ROCm initiative by AMD already "transpile" most CUDA kernels to being AMD compatible, but it seems performance is not yet comparable in real word benchmarks.
"We are excited to present ROCm, the first open-source HPC/Hyperscale-class platform for GPU computing that’s also programming-language independent. We are bringing the UNIX philosophy of choice, minimalism and modular software development to GPU computing. The new ROCm foundation lets you choose or even develop tools and a language run time for your application."
You should try Arch. I'm using AMDGPU with X11 on Arch since late 2015 (when full support for my card entered the mainline kernel) and I had exactly zero issues. Just installed the driver packages, rebooted and everything worked (xrandr, power mgmt, OpenGL, games, etc.).
Maybe your issue is trying to use the proprietary blobs (aka AMDGPU-PRO). I never used these (and I don't know why I should).
Yeah, OpenCL is a problem, clover crashes, the new AMD OpenCL driver is not ported yet (I guess it depends on kernel 4.15? we have amdgpu from 4.12 for now)...
I wish people started using Vulkan for compute instead of OpenCL!!
I did try their proprietary drivers, too, but did not have any luck. Maybe I'll have time to tinker with it tomorrow. It would have been nice to have out of the box support :) I suppose they will get there eventually.
Based on the positive comments wrt. the amdgpu driver I bought an AMD FirePro W2100 (because its max TDP is 25W). And it's been excellent. Since GCN 1.0 and 1.1 are supported by both the radeon and amdgpu drivers, I use the kernel flags
amdgpu.si_support=1 radeon.si_support=0 amdgpu.cik_support=1 radeon.ciksupport=0
Not in my experience. AMD efforts are welcomed by Linux community, especially gamers.
See trends here (AMD GPU usage is growing): https://www.gamingonlinux.com/users/statistics#trends
Check out https://math.dartmouth.edu/~sarunas/amdgpu.html
If you're on Debian instead of Ubuntu you can manually install the debs.