Announcement

Collapse
No announcement yet.

How Ubuntu 16.04 Is Performing With AMDGPU/Radeon Graphics Compared To Ubuntu 14.04 With FGLRX

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

  • #41
    Originally posted by artivision View Post

    I wander, for a single thread game Like FFXIII, if CSMT can cut some of the D3D mechanism from the game mechanism and give it to a second thread. Also if Nine can have any benefit from CSMT.

    if game gpu limited: no gain possible
    if game cpu limited: according to some old ATI docs, they gained only a few % going multithreaded, because most of the cpu usage is app side, and not driver side (we observe the same pattern with gallium nine).

    For the games shown the fact it is not 100% is just the hw not being utilised an optimal way. Better resource placement, shader code generation, some performance bits, etc are needed to get maximum performance. This work has to be done in the gallium driver, not gallium nine.

    Comment


    • #42
      Originally posted by bridgman View Post
      Not sure about specific control panel plans, but the general intention is to replace the Catalyst stack with a similar stack based on the all-open core.

      Again, the breaking news here is not "only open source drivers forever", just "we're replacing Catalyst with hybrid stack and so current Catalyst is not going into 16.04".
      Any chance features like FluidMotion will make an appearance with the new stack?

      Comment


      • #43
        Unless you are planning on playing games, I guess the differences are not noticable for normal use? Libreoffice, web-browsing, etc?

        Comment


        • #44
          Originally posted by mannerov View Post


          if game gpu limited: no gain possible
          if game cpu limited: according to some old ATI docs, they gained only a few % going multithreaded, because most of the cpu usage is app side, and not driver side (we observe the same pattern with gallium nine).

          For the games shown the fact it is not 100% is just the hw not being utilised an optimal way. Better resource placement, shader code generation, some performance bits, etc are needed to get maximum performance. This work has to be done in the gallium driver, not gallium nine.
          I don't mean what Nine must do to catch up with Windowz. I mean if we assume that both give the same framerate in the future, what Nine can do to kill Windows. I assume that Calls-Compiler-State cost 30-50% of the CPU and the game's general code the other 50-70%. For the D3D part now, isn't possible to forcibly cut it from the main thread if the game uses only one thread for both and doesn't fill the GPU not on Windowz or on Nine? I speak about D3D threaded optimizations.
          Last edited by artivision; 16 March 2016, 08:57 PM.

          Comment


          • #45
            Originally posted by artivision View Post

            I don't mean what Nine must do to catch up with Windowz. I mean if we assume that both give the same framerate in the future, what Nine can do to kill Windows. I assume that Calls-Compiler-State cost 30-50% of the CPU and the game's general code the other 50-70%. For the D3D part now, isn't possible to forcibly cut it from the main thread if the game uses only one thread for both and doesn't fill the GPU not on Windowz or on Nine? I speak about D3D threaded optimizations.

            It's more 5% D3D calls, and 95% application, so with multithread you can get max 5%. (except some corner cases where it is more than 5%)

            Comment


            • #46
              Did you use Steam games to get this working?

              I can't get steam to load with the r9 290 and the open drivers.

              Comment

              Working...
              X