The Qualcomm MSM DRM Driver Prepares To Switch To The "AMDGPU" GPU Scheduler

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67166

    The Qualcomm MSM DRM Driver Prepares To Switch To The "AMDGPU" GPU Scheduler

    Phoronix: The Qualcomm MSM DRM Driver Prepares To Switch To The "AMDGPU" GPU Scheduler

    The Freedreno-aligned MSM DRM driver for supporting Qualcomm Snapdragon hardware is preparing to make use of what was the AMDGPU DRM scheduler...

    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
  • bemerk
    Senior Member
    • Nov 2013
    • 271

    #2
    Is there an effort to make use of HDCP support across all gpu drivers as well? It would be nice if Linux could get a Widevine Level Upgrade.

    Comment

    • rene
      Senior Member
      • Jul 2015
      • 1489

      #3
      this kind of joined open source work and improvements is why nvidia's closed junk will fail in the long term. God knows what security issues, grave hacks, and benchmark cheating is hidden in it anyways.

      Comment

      • M@yeulC
        Senior Member
        • Dec 2013
        • 975

        #4
        Originally posted by bemerk View Post
        Is there an effort to make use of HDCP support across all gpu drivers as well? It would be nice if Linux could get a Widevine Level Upgrade.
        I for one disable that kind of stuff wherever possible, and avoid it like the plague. I wouldn't be surprised if other people had the same stance, to be frank.

        I get the "but you can't do without for X" argument, but you can always do without X in the end. Always. One of the few powers we have as consumers is to vote with our wallets, so I will continue doing everything I can not to feed that X

        Comment

        • robclark
          Senior Member
          • Sep 2011
          • 564

          #5
          Originally posted by M@yeulC View Post

          I for one disable that kind of stuff wherever possible, and avoid it like the plague. I wouldn't be surprised if other people had the same stance, to be frank.

          I get the "but you can't do without for X" argument, but you can always do without X in the end. Always. One of the few powers we have as consumers is to vote with our wallets, so I will continue doing everything I can not to feed that X
          Personally, not a huge fan of HDCP, but I am a fan of enabling driver support for the hw features that some users would want, and letting the users make their own choices. After all, choice and control is one of the benefits of free software. (And ofc as long as some users will want support, I think it is better to have that support in the upstream kernel where it gets review, rather than living on downstream branches.)

          So far we use a kconfig option so HDCP can be disabled/enabled at compile time. Open to the idea of module_param/etc to give more control without having to recompile kernel, or other suggestions.

          Comment

          • M@yeulC
            Senior Member
            • Dec 2013
            • 975

            #6
            robclark right, that's a sane stance, that I can agree with

            edit: although I would love to be able to supply my own keys for HDCP to prevent eavesdropping in secure environment, or for password entry, etc. Maybe the monitor could even perform a key exchange, and everything be encrypted between the GPU driver (or a program) and the screen. Also authenticate password prompts as being displayed by a trusted part of the OS? Food for thought... But that's not going to happen anytime soon, that kind of stuff noes not remotely have the kind of backing HDCP gets ^^"
            Last edited by M@yeulC; 05 October 2018, 07:15 AM.

            Comment

            Working...
            X