Announcement

Collapse
No announcement yet.

OpenSUSE Ends Support For Binary AMD Graphics Driver

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

  • #31
    Originally posted by leigh123linux View Post
    You obviously have never packaged before
    Lol :P

    Originally posted by leigh123linux View Post
    I've actually tried to package fglrx driver without hardware to test.
    The results weren't good and didn't function .
    That's why you open a bug report section somewhere, it can even be just a forum thread.

    I guess the most important step in re-building is to notice the difference in the folders, scrips, services, etc, between the two distros.


    Originally posted by leigh123linux View Post
    I guess that doesn't matter with Arch which seems to be broken most of the time
    Oh please, let's not start this debate Any Arch user knows how stable it is. I guess you haven't tried it yet?

    Comment


    • #32
      Originally posted by jaxxed View Post

      I'm pretty sure that you aren't actually compiling the PRO package, as it isn't distributed in source (I thought.) Do you mean the aur support which extracts the binary from the debian package(s)?
      Oh yeah, thanks. Fixed.

      Comment


      • #33
        Am I the only one here who has seen *major* thermal issues with the open source drivers for Radeon graphics? It doesn't personally affect me because I only buy hardware with Intel graphics. But I have installed Linux for countless friends and family members, and unfortunately I have to say that the open source drivers for Radeon hardware simply don't cut it. Performance is good enough to watch videos (not a gamer), so no complaints there, but the thermal performance is absolutely abysmal on every single laptop I have tested with Radeon hardware. It's so bad that the laptop overheats to the point of triggering BIOS-level CPU throttling, and gets uncomfortably hot to the touch. Those same laptops all used to run Windows with no thermal issues at all, so it's not due to clogged ventilation pathways.

        Comment


        • #34
          Originally posted by Delgarde View Post

          Uh, no. If you're a packager, it's generally considered good practice to test that your package actually works.
          It sure is, but if the packages doesn't have the hardware he shouldn't just completely drop the package as there are many people who need it.

          By dropping the packages he/she is forcing a lot of people away from openSUSE, the distro I most recommended when talking about AMD drivers because their integration was very good and easy.

          Comment


          • #35
            Originally posted by Amarildo View Post
            I forgot to mention: the 500 FPS was just an indicative of how both Windows and FGLRX can extract the most out of my hardware, while Mesa isn't able to do so yet in many games.
            Which, I'm sure you realize doesn't matter one tiny little bit if you're already over the monitors refresh rate right? Of course you do, otherwise so far all your posts in this thread is complaining about a "problem" that actually isn't a problem at all.

            EDIT: The point being 250fps is exactly equal to 500 fps in every single scenario.

            Comment


            • #36
              Originally posted by LEW21 View Post

              Bullshit.

              I'm the one, who has originally packaged amdgpu-pro for Arch, and put the package in AUR. I didn't have supported GPU at that time, and was unable to test it. True, the driver was packaged. But it didn't work, and it required a lot of work by somebody with a supported GPU to be really usable - https://github.com/corngood/archlinu...commits/master
              Notice I said "build it", not "test it". As I said before, I think dropping the packages shouldn't be the way to go just because he doesn't have the hardware to test it.

              You, LEW21, did a great job on putting it there first. This way, people that actually have the hardware could try it and submit fixes for everybody. I do know it helps a lot if the packager can test the pacakge, but it shouldn't be a requirement for building it.

              Comment


              • #37
                Personally I think all bar graphs should be capped at monitor refresh and -any- result higher then that should simply be truncated. At least that way people that don't know any better could easily see that the performance equals exactly the same difference.

                Comment


                • #38
                  Originally posted by duby229 View Post

                  Which, I'm sure you realize doesn't matter one tiny little bit if you're already over the monitors refresh rate right? Of course you do, otherwise so far all your posts in this thread is complaining about a "problem" that actually isn't a problem at all.

                  EDIT: The point being 250fps is exactly equal to 500 fps in every single scenario.
                  Yes, I do. My posts are only to show the difference in hardware use between both drivers, which is reflected in other titles as well.

                  Comment


                  • #39
                    Originally posted by mlau View Post

                    Well then I suggest you step up and take over maintainership of the amdgpu-pro driver on opensuse if it's that easy for you.
                    Looking forward to seeing your packages in the repo!
                    I have zero experience in building packages in openSUSE, so I can't take the job.

                    I was, however, thiking on putting up the scripts to build "amd-staging-4.7" in the AUR, with support for GCN 1.0 cards, but I'm not sure that would be useful to many people. Not to mention it's really easy to just grab "linux-git" and change the source in the PKGBUILD to point to whatever new Kernel the user wants.

                    Comment


                    • #40
                      Originally posted by Amarildo View Post

                      Yes, I do. My posts are only to show the difference in hardware use between both drivers, which is reflected in other titles as well.
                      Which does not matter at all. You cannot extrapolate benchmark results between games even if they use the same engine. Any game that plays over your monitors refresh rate has already achieved that "good enough" status. From that point forward development effort needs to be spent on games that haven't hit that point yet. Which fortunately is exactly the scenario we've been in for years already.

                      EDIT: This is exactly why Vulkan adoption is soooo important. It becomes the game engine developers job to optimize and the graphics drivers job to standardize. I can't wait for it.
                      Last edited by duby229; 08 December 2016, 02:16 PM.

                      Comment

                      Working...
                      X