131–140 of 181 posts
Earlier quoted context omitted.
When hell freezes over. Their management seems stuck to agressive anti-FOSS stance forever. Shame to every developer who works for them - it is like working for the evil.
I keep wondering where Oracle and Nvidia come up with their developers. I don't want to work at either because of their complete disregard for FOSS, and most developers I know have the same opinion.
Remember, Comcast also has software developers.
Earlier quoted context omitted.
From my perspective (computational physics, not machine learning) the situation with GPU compute is very simple. If you are fine writing everything from scratch and won't need the CUDA ecosystem (which is really all there is for good sparse matrix, linear algebra, etc. support), write OpenCL 1.2 (or even GLSL if it's a visualization-heavy code with relatively simple compute) and buy whatever gets you the best compute…
AMD's hardware is stupid-good from a compute perspective. Vega64 is $399, but renders Blender (on AMDGPU-PRO drivers) incredibly fast, like 2080 or 1080 Ti level. That's basically the main use case I bought a Vega for (which is why I'm very disappointed in ROCm's current bug which breaks Blender) If you really can use those 500GB/s HBM2 stacks + 10+ TFlops of power, the Vega is absolutely a monster, at far cheaper pr…
As one example, I have a recurring task that runs on my GPU in the background, and I sleep next to the computer that does that. Since I don't want it to be too noisy, and it is acceptable for it to take longer to run while I'm asleep, I have a cron job which changes the power cap through sysfs to a more reasonable 45W (and at those levels, it's much more efficient anyhow, especially with my tuned voltages) at night.
> I really wonder why video games FPS numbers are so much better on NVidia. The compute power is clearly there, but it just doesn't show in FPS tests.
Drivers are hard, and AMD has sorta just been getting around to doing them well. The Mesa OpenGL drivers are usually faster than AMDGPU-PRO at OpenGL, and RADV is often faster than AMDGPU-PRO Vulkan (and AMDVLK).
I've been hoping these last few years that AMD would try to ship Mesa on Windows (i.e., add a state tracker for the low level APIs underlying D3D), and save themselves the effort. As far as I can tell, there is no IP issue preventing them from doing that (including if they have to ship a proprietary version with some code they don't own). There still seems to be low-hanging fruit in Mesa, but the performance is already usually better.
A lot of people are talking along the lines of "oh AMD is nice but... Nvidia". No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). For gaming though, theres no reason not to get an AMD GPU. They are at near performance parity with Nvidia relative to their Windows…
Cemu, yuzu and any other cpu-intense emulators which only support opengl. The mesa drivers are much faster (you can get 40% more performance out of cemu my running it on Linux via wine) but this doesn't help windows AMD users.
Earlier quoted context omitted.
I thought it was interesting how they began forcing Windows users through a login page to associate identity, and a continuous background telemetry service, but not Linux users. The telemetry service needs to be running just to check for updates to the gaming card drivers. At least, I personally didn't have that experience on Linux with proprietary driver when the Windows gaming rig did. They likely determined it was…
You need to login for GeForce Experience not for driver. GFE is optional.
If you want to install just the driver, you have to extract the driver from their executable and manually handle updates, or use a third party package manager like chocolatey.
Most people won't know this is possible. The trade-off to the vast majority is to trade unknown bits of their information for security and stability updates.
Should that really be the default state of things?
A lot of people are talking along the lines of "oh AMD is nice but... Nvidia". No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). For gaming though, theres no reason not to get an AMD GPU. They are at near performance parity with Nvidia relative to their Windows…
> CUDA
Implemented by AMD too, under the moniker "hip."
> their RTX crap
Vendor-independent via DXR, soon to be available through Vulkan as well.
> Gsync
Nvidia GPUs now work with freesync monitors
> Physx
Open source, as of december.
I want to feel good about AMD, but they have thus far failed to build a stable platform around their GPGPU stack(s). Nvidia has done a pretty good job with making CUDA a stable platform for SW development, however anti-competitive you might think it is.
Earlier quoted context omitted.
Yet I can still not read CPU core temperatures of my ryzen 2600 on Linux (5.0-rc2). I am not sure what is going on but I think next time I'll go with Intel again. I read this may be related to some NDA by AMD but not sure.
just when AMD looks like they will be the safe bet on CPU for the next few years you bolt? =)
A lot of people are talking along the lines of "oh AMD is nice but... Nvidia". No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). For gaming though, theres no reason not to get an AMD GPU. They are at near performance parity with Nvidia relative to their Windows…
> they work with the inbuilt drivers on every distro out of the box No they don't work with any distro that uses linux-libre.
Earlier quoted context omitted.
Proprietary drivers are the worst kind of propreitary software. If the vendor goes bankrupt or simply chooses to stop supporting your product, you have no path forward to update your operating system. Why use a Canon printer when HP has open source drivers? Why use Nvidia when AMD has drivers in the kernel that will never be removed. Old Nvidia cards like a GTX 8800 have only poor reverse engineered support on recent…
> Why use Nvidia when AMD has drivers in the kernel that will never be removed. It's perfectly reasonable to be concerned about a vendor going bankrupt and choosing not to support their product. If that's the issue, just don't buy their products. If one thinks that CUDA functionality is really that important, then isn't that proof that it's valuable IP? Nobody should be forced to open up valuable IP. I don't think it…
Also, I don't think that someone is bad for making use of crappy laws such as IP laws, but I don't think we want to have that discussion here.
Earlier quoted context omitted.
Yet I can still not read CPU core temperatures of my ryzen 2600 on Linux (5.0-rc2). I am not sure what is going on but I think next time I'll go with Intel again. I read this may be related to some NDA by AMD but not sure.
Temperature monitoring for the first gen Ryzen chips has been in the kernel for about a year. The patch for second gen is there but narrowly missed the 5.0 release window, so it should land in the first release after 5.0. Intel is a bit faster about this but it's not like they have perfect day 1 kernel support either. i.e. temperature monitoring drivers for both first gen Ryzen and Coffee Lake landed in 4.15. At the…
A lot of people are talking along the lines of "oh AMD is nice but... Nvidia". No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). For gaming though, theres no reason not to get an AMD GPU. They are at near performance parity with Nvidia relative to their Windows…
> No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). To be fair, only Intel has good OpenCL 2.0+ support. NVidia isn't really pushing OpenCL and AMD's ROCm OpenCL driver is still a bit unstable. AMD's OpenCL 2.0 support has always been poor. The Windows OpenCL 2…
And they are doing it again with Vulkan. With a large majority looking for higher level wrappers instead of dealing directly with its APIs and increasing number of extensions.