Originally posted by birdie
View Post
Announcement
Collapse
No announcement yet.
Linux 5.9 Brings Safeguard Following NVIDIA's Recent "GPL Condom" Incident
Collapse
X
-
Originally posted by birdie View Post[...] The RX 5000 series does not support HW accelerated video decoding yet via the open source Mesa stack. End of freaking story. AMD fans cannot even read - they can only posture.Code:% vainfo libva info: VA-API version 1.8.0 libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_8 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.8 (libva 2.8.0) vainfo: Driver version: Mesa Gallium driver 20.2.0-rc2 for AMD Radeon RX 5700 (NAVI10, DRM 3.38.0, 5.8.0, LLVM 10.0.0) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileJPEGBaseline : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile2 : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProcvainfo
- Likes 17
Comment
-
Originally posted by torsionbar28 View PostAlso the part where there is a proprietary AMDGPU-PRO driver that is not FOSS but tends to be a bit ahead in terms of compatibility and stability. Not sure why birdie would bother with changing hardware, seems like poor troubleshooting on his part. My Vega56 card is rock solid stable on Ubuntu 20:04 for Steam gaming, and it does all the things you would expect, like video decoding and encoding, etc.
How long have you had your Vega56 for? IIRC, they didn't have the best reputation around these parts for the first year or so. Just curious if you had to go through, for a lack of a better term, the growing pains of the driver being developed or if you bought in after a year of so. Anecdotally, it seems that people who go through the growing pains are more critical of AMD than either people who bought in afterwards and didn't deal with the major bugs or the general AMD Linux enthusiast who wants them to succeed.
I've had my Polaris card since February last year. An RX 580. Would have bought it a few months sooner but that was when GPU inflation hit and I refused to pay those prices unless forced. By the time I bought it all the major platform bugs and kinks had been worked out during the 4XX Polaris generation so I was able to buy into a refined platform with a more mature driver where my biggest issue is software would say RX 480 instead of RX 580. I'd have held out a few months longer for GPU prices to go back down but my 260x was 7 years old and started getting coil whine with random crashes so I was forced into an upgrade and I'm damn glad it happened. I'm in the category of enthusiast who wants them to succeed but also reads tech blogs and doesn't buy day one hardware.
Oh snap, just realized I can finally start downloading the THPS Warehouse demo
- Likes 2
Comment
-
Originally posted by BtbN View PostSo people pushing ideologies are once again making life harder for people who just want to use their hardware.
I'm surprised BSD isn't getting more traction due to this, to then eventually just give up on Linux. Would save a lot of headaches.
- Likes 4
Comment
-
I have a 5700XT and run Kernel 5.8, the "amdgpu" driver is quite stable for me. Performance is good, no crashes..
I had random blackscreens with older kernel though!
Only problem that persists: Monitor stays black when i turn of the monitor and turn it on again.. However sleep / standby / wakeup works!
Although i had similar problems with a GTX 970 on windows with the same monitor, so the monitor not behaving correctly regarding display port protocols could be a factor here.
- Likes 3
Comment
-
Originally posted by Spacefish View PostI have a 5700XT and run Kernel 5.8, the "amdgpu" driver is quite stable for me. Performance is good, no crashes..
I had random blackscreens with older kernel though!
Only problem that persists: Monitor stays black when i turn of the monitor and turn it on again.. However sleep / standby / wakeup works!
Although i had similar problems with a GTX 970 on windows with the same monitor, so the monitor not behaving correctly regarding display port protocols could be a factor here.
Comment
-
Originally posted by birdie View Post
i mean, what kind of sane person runs navi with 5.6? don't get me wrong, i have nothing against nvidia, i wish them well. but switching from amd to nvidia because of problems caused by outdated kernel and/or mesa, then throwing sh.. at amd on the forum is just silly at best, trolling at worst.
Originally posted by birdie View PostNot a single person on Earth is able of auditing the entire source code of the Linux kernel and proving it does not have backdoors or malicious functions. Again, sanity is not strong with this one. You're absolutely delusional in pretty much everything you're saying.
Originally posted by birdie View PostBuying an AMD CPU along with an AMD GPU and finding critical bugs (shown in the thread earlier) in the AMD open source drivers is shilling for NVIDIA. Right. Open Source fans have no common sense and logic.
Originally posted by JustK View PostCode:% vainfo libva info: VA-API version 1.8.0 libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_8 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.8 (libva 2.8.0) vainfo: Driver version: Mesa Gallium driver 20.2.0-rc2 for AMD Radeon RX 5700 (NAVI10, DRM 3.38.0, 5.8.0, LLVM 10.0.0) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileJPEGBaseline : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile2 : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProcvainfo
now, i'm not saying there are no bugs - far from it. heck, i'm running kaveri and i had some problems months ago, seemed to calm down after switching from 4.19 to 5.6 and some mesa updates - and that's a pretty old hardware already. but to be fair, those were mostly caused by me testing every possible option to reach maximum performance, like gl_threads, or caused by the combination of dxvk and a game screwing up resource management, like gta v running out of vram (i got rid of hangs caused by gta v by changing amdgpu.gttsize and limiting vram usage with dxvk.conf - that just shows how many factors are there to each possible crash).
with opensource drivers, running the latest kernel and mesa with default settings is the first step to eliminate problems. also, at least on kaveri i've found radv to be more stable than amdvlk - the latter was causing some non-critical kernel errors in some games, whereas radv is just stable and works as supposed. so while i 100% agree that it's not all bug-free, the actual quality of the drivers is pretty high.
and disclaimer, if i were to chose a dedicated gpu right now, i would pick nvidia, simply because at the <=75W range amd has nothing reasonable. hopefully navi 2 will change that, and hopefully nvidia will change their attitude towards linux kernel. bottom line is, each choice has its drawbacks and each driver has its problems. "shilling flamewars" are not a solution.
- Likes 8
Comment
-
I noticed that almost all of this entire thread went sideways into graphics card support and gaming simply due to the mention of NVIDIA. I guess that happened due to the original article requiring deeper diving to understand it's actual topic. So this article is "unintentional clickbait" IMHO.
I wonder if anyone bothered to look over the actual code that was submitted to see the use case being considered? I did. It looks like a machine learning application that uses GPUs for the processing and Mellanox for the networking. It's an approach to offload networking processing from the CPU to the GPU in this use case, which seems reasonable to consider.
Could it be leveraged into other networking things? Perhaps.
Is this code evil? You'll have to define your subjective feelings on that in an objective manner to intelligently argue them. Just because "IT'S NVIDIA!!" is not enough.
Do I agree with the comments by Greg KH about the quality of the submitted code? Yes, it is SLOPPY by kernel standards (when you have to tell a submitter to run 'checkpatch' before submission /facepalm/) and in other ways (the entire GPL symbol exporting code in it is a hot mess), but it doesn't mean this technical area (high bandwidth, HW accelerated networking for machine learning) should not be investigated for inclusion in the Linux kernel.
Last edited by NotMine999; 14 August 2020, 12:42 PM. Reason: Phoronix kept timing me out while writing this - most annoying
- Likes 3
Comment
Comment