Announcement

Collapse
No announcement yet.

9-Way RadeonSI GPU Tests On Mesa 17.1 + Linux 4.11

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

  • #11
    Originally posted by dungeon View Post
    sort of opensource guys say OK to some blobs, but free software say No to all of these blobs
    this is incorrect. free software has lgpl specifically for linking with blobs

    Comment


    • #12
      Originally posted by pal666 View Post
      this is incorrect. free software has lgpl specifically for linking with blobs
      I call that Lesser No license

      Comment


      • #13
        When will the R9-290 be properly supported!?!? Geeez!
        I'm on 4.4.0-72-generic with Padoka stable because that's the only mesa-kernel combo I can get working correctly with good FPS and no graphical bugs! In the meantime I'm missing out on all the goodness that newer kernels have to offer!

        Turning off RadeonSi and switching to AMDGPU is just too much stuffing around and not easy enough for the average Joe! grrrr

        Comment


        • #14
          Originally posted by dungeon View Post
          Well, Stallman types you mentioned are free software guys that is different than opensource... sort of opensource guys say OK to some blobs, but free software say No to all of these blobs
          Again with the semantics? Let's not forget about LGPL which obviously wouldn't have allowances for blobs if Stallman types that anal about staying away from blobs.

          Originally posted by pal666 View Post
          it is the other way around: between { {fast vulkan for two opengl games} + { shitty opengl } } with blob and { { fast and robust opengl which works with all linux games } and { nine for windows games } } with upstream working out of the box linux drivers only idiot will choose blob
          If I'm not mistaken AMDGPU-PRO is generally tends to be the faster driver in synthetic benchmarks and games before game specific optimizations are cooked up and mainlined. RadV isn't on par with AMDGPU-PRO even feature wise and don't even get me started on OpenCL support.

          Also try to remember that lately most of the AMDGPU-PRO development effort has recently been to get DC into shape for mainlining and to support the upcoming Vega hardware, which won't be supported in the open source drivers until DC is mainlined. Once that's done you can be pretty sure that AMD's blob developers are going to start making headway on open sourcing and performance enhancements.

          Comment


          • #15
            Originally posted by L_A_G View Post
            Again with the semantics? Let's not forget about LGPL which obviously wouldn't have allowances for blobs if Stallman types that anal about staying away from blobs.
            Well, if it is not that what "Stallman types" meant to you? People with a beards or something?

            Comment


            • #16
              Originally posted by L_A_G View Post

              I'm pretty sure very few people are going to be switching between drivers for Vulkan and OpenGL. When you're getting very similar performance with one API and much better with the other API, then that's what people are going to be using unless they're Stallman types. Then again this is Phoronix so Stallman types are obviously pretty common, thou I wouldn't say they're the norm or majority.

              Personally I don't see much of a point in RadV beyond a fallback in case AMD decides not to open source AMDGPU-PRO. The instant AMDGPU-PRO is made open source, it'll be made redundant and I personally hope most of it's developers will stop wasting their time working on it as it'll just be another NIH syndrome project. Sort of like Mir.
              Actually it should happen backwards, RADV is getting so close in features and performance that i don't think AMD is going to open source theirs at all but just add manpower and some code to speed RADV up to date with the standard.

              between mesa-git and patchworks pretty much all relevant features are supported(actually i think doom 2016 should run in mesa git without patches or is very very close) and they works pretty well even on SI cards(My old and trusty r9-280 loves it).

              Another big plus is RADV uses mesa existent infrastructure and LLVM compiler and share lot of code with Intel ANV(when possible) too, which helps a metric ton with things like keeping WSI as bug free as possible

              Comment


              • #17
                Originally posted by dungeon View Post
                Well, if it is not that what "Stallman types" meant to you? People with a beards or something?
                Got dyslexia or something because I already explained what I meant.

                Here's the same thing hoping you'll actually read it this time: People who use open source software not because it's better, but because it's open source.

                Comment


                • #18
                  Originally posted by L_A_G View Post

                  Got dyslexia or something because I already explained what I meant.

                  Here's the same thing hoping you'll actually read it this time: People who use open source software not because it's better, but because it's open source.
                  I can read that again, but Stallman types AFAIK does not use term open source - they rather speak of free/libre software... so i don't understand that your's mixed meaning of Stallman types

                  Comment


                  • #19
                    Originally posted by L_A_G View Post
                    If I'm not mistaken AMDGPU-PRO is generally tends to be the faster driver in synthetic benchmarks and games before game specific optimizations are cooked up and mainlined.
                    you are mistaken
                    Originally posted by L_A_G View Post
                    Also try to remember that lately most of the AMDGPU-PRO development effort has recently been to get DC into shape for mainlining and to support the upcoming Vega hardware, which won't be supported in the open source drivers until DC is mainlined.
                    you are delusional. amdgpu-pro doesn't require dc mainlining, so it was most of non-amdgpu-pro development effort

                    Comment


                    • #20
                      DanglingPointer AFAIR the issue with the R9 290 is Ubuntu related, you could try a live image of another distro to check if the issue still exists

                      Comment

                      Working...
                      X