Announcement

Collapse
No announcement yet.

Mesa Has Already Seen More Code Changes This Year Than All Of 2015

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Azrael5 I answered you in a post that got unapproved, it should appear above this post.

    Comment


    • #32
      Originally posted by dungeon View Post
      No, 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'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. 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


      • #33
        Originally posted by starshipeleven View Post
        How 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.
        about this: In my case I falsh vga bios using another PCI vga. So it is simple to eventually unbrick the vga:
        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


        • #34
          Originally posted by duby229 View Post
          I'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.
          Nope, you said your reasoning in first comment in this thread so there is no need to hold any middle ground now

          Originally posted by duby229 View Post
          Oh, Hellz to the Motha' F___in' Yeah Dawg!! Eat shit and die proprietary drivers!

          Comment


          • #35
            Originally posted by dungeon View Post

            Nope, you said your reasoning in first comment in this thread so there is no need to hold any middle ground now


            ...

            Comment


            • #36
              Originally posted by duby229 View Post
              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.
              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.
              Test signature

              Comment


              • #37
                Originally posted by Azrael5 View Post
                Linux has to match simplicity because simplicity makes the system harmonious. simplicity harmonizes the complexity.
                This seems like a great signature line. I have no idea what it means, but I love the way it sounds.
                Test signature

                Comment


                • #38
                  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.
                  I really do hope to see it completely synced to upstream though. It would solve that problem too.

                  Comment


                  • #39
                    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.
                    It is not installer related, any distro can repackage that anyway... You probably don't need native installer model for else, for amdgpu-pro beside debs actually i think you should just provide also so called orig package (like steamos pro package do) so that other distros can easely manage it their way from there.

                    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


                    • #40
                      Originally posted by smitty3268 View Post
                      For 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.
                      Thanks! Now that makes sense.

                      Comment

                      Working...
                      X