Announcement

Collapse
No announcement yet.

Linux 3.15 Kernel Released

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

  • Linux 3.15 Kernel Released

    Phoronix: Linux 3.15 Kernel Released

    The Linux 3.15 kernel has now been released...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Cheers

    Comment


    • #3
      Originally posted by deadite66
      Shame about the UVD regression though.
      Come on. In the long term, that reduced clocks get us "cooler" hardware and less power consumption. And when they take postprocessing into account and keep the gpu clocks up, all is fine. Check the great other stuff that was implemented for AMD in that version (vblank optimizations, suspend / resume fixes and a lot more).

      And btw: You did not report that issue during all RCs - so don't complain on release day.

      Comment


      • #4
        Also Linus has now officially send his message on 3.15:



        So I ended up doing an rc8 because I was a bit worried about some
        last-minute dcache fixes, but it turns out that nobody seemed to even
        notice those. We did have other issues during the week, though, so it
        was just as well. The futex fixes and cleanups may stand out, but as
        usual there's various other random fixes since rc8 in there too:
        mainly drivers (drm, networking, sound, usb etc), networking,
        scheduling and perf tooling.

        But it's all been fairly small and quiet, which *may* of course be due
        to the fact that last week was also the first week of the merge window
        for 3.16. That might have distracted some developers. I'm not entirely
        convinced I liked the overlap, but it seemed to work ok, and unless
        people scream really loudly ("Please don't _ever_ do that again") and
        give good reasons for doing so, I might end up doing that overlapping
        merge window in the future too if it ends up helping out with some
        particular timing issue.

        That said, I also don't think it was such a wonderful experience that
        I'd want to necessarily do the overlap every time, without a good
        specific reason for doing so. It was kind of nice being productive
        during the last week or rc (which is usually quite boring and dead),
        but I think it might be a distraction when people should be worrying
        about the stability of the rc.

        Of course, maybe the overlap ends up meaning that we get less noise
        during the last week of stabilization, and it actually helps. It could
        go either way. I'd be interested to hear what people thought, although
        I _suspect_ most people don't feel strongly either way.

        Anyway, with 3.15 released, my "master" branch has already merged the
        work in my "next" branch on my local machine, and I'll be
        decommissioning the "next" branch once I push that all out. After
        that, any future merge window work will happen on "master", and we'll
        be back to the normal single-branch model for my tree.

        Linus

        Comment


        • #5
          Originally posted by deadite66
          Shame about the UVD regression though.
          What UVD regression? I know radeon is popular, but kernel is not all about radeon driver .

          Beyond rc8 have couple fixes for radeon too, so just compiled it... have Athlon 5350 here, works fine .

          Comment


          • #6
            Originally posted by dungeon View Post
            What UVD regression? I know radeon is popular, but kernel is not all about radeon driver .

            Beyond rc8 have couple fixes for radeon too, so just compiled it... have Athlon 5350 here, works fine .
            The new dynamic UVD clocks, clock a bit too low (especially also the GPU), so that E-series can't do decoding and postprocessing with the temporal deinterlacer (mesa 10.2) at once.
            See here: http://lists.freedesktop.org/archive...ry/054361.html

            You might realize it, when you decode 1080p60 or 1080p50 content and when doing postprocessing, but that's all, just a minor already identified regression, which can be fixed easily.

            Comment


            • #7
              What Alex says:

              If that becomes an issue, we can add a sysfs attribute to force the max UVD state.
              So is there option to force max? I guess deadite66 will be satisfied with that .

              Comment


              • #8
                Originally posted by deadite66
                i tried changing /sys/class/drm/card0/device/power_dpm_force_performance_level but it won't budge off auto, so nothing in place.
                That option is about DPM, not about UVD.



                BTW not sure why that is not working for you, maybe it is not supported on all chips...

                Comment


                • #9
                  Yay. Now hopefully Gentoo will stabilise 3.14 in three weeks time. (That would allow me to ditch Catalyst without unmasking the kernel version manually while I'm upgrading razor-qt to lxqt. Small things, but would make my day )

                  Comment


                  • #10
                    Originally posted by GreatEmerald View Post
                    Yay. Now hopefully Gentoo will stabilise 3.14 in three weeks time. (That would allow me to ditch Catalyst without unmasking the kernel version manually while I'm upgrading razor-qt to lxqt. Small things, but would make my day )
                    You mean 3.15? Right?

                    Code:
                    navarro ~ # uname -a
                    Linux navarro [B]3.14.5-gentoo-r1[/B] #1 SMP PREEMPT Sat Jun 7 11:12:32 CEST 2014 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux

                    Comment

                    Working...
                    X