Azrael5 I answered you in a post that got unapproved, it should appear above this post.
Announcement
Collapse
No announcement yet.
Mesa Has Already Seen More Code Changes This Year Than All Of 2015
Collapse
X
-
Originally posted by dungeon View PostNo, i don't make waves. It is true that i am actually very long time opensource driver user and still i am and it is true that i switched to try Catalyst last year.
And i switched there just to checked out what in the hell people complain about it there... opensource guys complain so much at time and now still about those blobs to the point that that became total unreal and for real i did not found much wrong there, other then some parts or most are blobs... what is wrong with this other then that i dunno, nothing - i actually found it is unbreakable stable in comparison to oss
I will say this though, I haven't had any major issues with amdgpu-pro yet, but that isn't true for catalyst. Despite your flat out bold lies Catlyst is broken and never be recommended to anyone. Thank god the systems where catalyst can be recommended is shrinking fast.
Comment
-
Originally posted by starshipeleven View PostHow totally unexpected, all programs that flash stuff can erase the ROM in the devices they are flashing, and if something goes wrong they can brick them.
as far as your comment to my observation: I haven't read it but I search to imagine what your long comment means.
I use also microsoft operating systems: to manage devices I can read info on device manager, windows device information, dxdiag, on the control panel of the main devices other than see this information by specialized information utilities. About flash: there are several utilities to flash bios from DOS or windows. There few commands, the file and the operation. How the site are made: there is the main page the download page the description of the program which explains how to use it. Simple method to use it and simple explanation.
Why windows operating system had success: because it is intuitive and immediate. It passes from programming to utilization of the programs.
If I see a program as flashrom I'm not in the utilization ambient, I'm in the programming ambient. Linux developers still don't understand this difference. To know about my hardware the final user must not write sudo lshw in the shell, he has to open a program as HWINFO reading in coherent way the features of every devices listed. So how to flash firmwares: I open the program I select the device I load the firmware and flash it. Or I use the old method: DOS: program options firmware. It is simple to understand.
Linux has to match simplicity because simplicity makes the system harmonious. simplicity harmonizes the complexity. Although many improvements are made, linux operating systems still lack this vision.
Comment
-
Originally posted by duby229 View PostI'm at the maximum upper limit to how much I -think- I can disagree....
I will say this though, I haven't had any major issues with amdgpu-pro yet, but that isn't true for catalyst.
Originally posted by duby229 View PostOh, Hellz to the Motha' F___in' Yeah Dawg!! Eat shit and die proprietary drivers!
Comment
-
Originally posted by duby229 View PostI will say this though, I haven't had any major issues with amdgpu-pro yet, but that isn't true for catalyst. Despite your flat out bold lies Catlyst is broken and never be recommended to anyone. Thank god the systems where catalyst can be recommended is shrinking fast.
We have moved away from the native installer model with amdgpu pro, but the requirement for code paths covering every kernel and X variant is pretty much unavoidable in an out-of-tree driver.Test signature
Comment
-
-
Originally posted by bridgman View Post
My impression was that a lot of our "Catalyst problems" were install-related, ie if the installer did the right thing for your specific system AND the driver had the right X/kernel compatibility code for your specific combination of components things worked reasonably well, but if not then Bad Things happened.
We have moved away from the native installer model with amdgpu pro, but the requirement for code paths covering every kernel and X variant is pretty much unavoidable in an out-of-tree driver.
Comment
-
Originally posted by bridgman View Post
My impression was that a lot of our "Catalyst problems" were install-related, ie if the installer did the right thing for your specific system AND the driver had the right X/kernel compatibility code for your specific combination of components things worked reasonably well, but if not then Bad Things happened.
We have moved away from the native installer model with amdgpu pro, but the requirement for code paths covering every kernel and X variant is pretty much unavoidable in an out-of-tree driver.
But really first advised procedure does not actualy changed at all with amdgpu-pro it is same as Catalyst's , so put those files here and there and build module... and if everything else found and expected is there so align to it, it works fine for an end user
Of course opensource people will always complain, because not all source code is in their hands
Comment
-
Originally posted by smitty3268 View PostFor a while he's been saying to use the proprietary drivers because of some bugs he is worried about in the OSS ones, but before that he was all about using the OSS drivers. So he just likes to make waves, I don't think he's got a strong political view on them.
Comment
Comment