Announcement

Collapse
No announcement yet.

Allwinner A33 DRM Support Coming In Linux 4.9

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

  • Allwinner A33 DRM Support Coming In Linux 4.9

    Phoronix: Allwinner A33 DRM Support Coming In Linux 4.9

    Maxime Ripard of Free Electrons has sent in the Allwinner DRM driver pull request that will ultimately land for the Linux 4.9 kernel merge window...

    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
    Cool, and also lame. We need an open source mali driver.

    Comment


    • #3
      Reading 'Allwinner' always makes the phrase 'GPL violator' come forward from the depths of my brain.

      Comment


      • #4
        Originally posted by SaucyJack View Post
        Cool, and also lame. We need an open source mali driver.
        People expect libv to finish his work. After all it's his sole responsibility to do commercial quality GPU drivers without getting paid. Several companies have sold millions of Allwinner devices and are now becoming really desperate with this lima situation. Why won't libv finish the work for free? Maybe the situation with documentation is too good. Previously there was zero documentation. How about burning few books and turning the number into a negative value?

        Comment


        • #5
          Originally posted by caligula View Post

          People expect libv to finish his work. After all it's his sole responsibility to do commercial quality GPU drivers without getting paid. Several companies have sold millions of Allwinner devices and are now becoming really desperate with this lima situation. Why won't libv finish the work for free? Maybe the situation with documentation is too good. Previously there was zero documentation. How about burning few books and turning the number into a negative value?
          Never undervalue the satisfaction of free labor!

          No serious company would use a chip like the Allwinner series, really. Even the name is a total crap, so lame.

          Despite the shortcommings, I would really only use Intel SoCs if the requirements would be satisfied. Despite it may be not so good as many people claim....


          It may seem absurd, then, to suggest Intel should make Core readily available for budget computers, but that’s exactly what it needs to do if PCs are to remain relevant to the average person in the long run. Charging hundreds for a decent Core mobile processor can’t be sustained, and offering Atom as an alternative only hurts the user experience. It is true that Intel currently dominates the market for PC processors, but if it does nothing to counter current trends, it may find there’s not much of a market left to dominate.
          Source: Intel needs to kill the Atom before cheap PCs sour users on all PCs




          Does this mean that low-power laptops and tablets are dead?

          Nope. An Intel spokesperson tells Liliputing that the company will “continue to work with OEMs to develop new 2-in-1s based on Apollo Lake” as well as Intel Core M chips. So while Atom chips will eventually be phased out, we’ll continue to see low-power tablets that offer somewhat better performance… most likely at a higher cost.

          And the company will continue to push its Core M chips for higher-priced, higher-performance devices. These chips don’t use much more electricity than an Atom processor, but offer significantly better CPU and graphics performance. Computers with Core M processors often sell for twice the price (or more) of a similar model with an Atom chip, though.

          For instance, the 2016 Intel Compute Stick mini PC with an Intel Atom Cherry Trail processor is priced atabout $140, while a model with a Core M processor sells for closer to $400.
          Source: Intel is killing off low-power Atom chips (for smartphones and PCs)


          I would consider because Open Source drivers and a big brand on it, that pays developers instead having amateur projects like Linux-Sunxi that really lag behind in support in comparison. I really hate ARM systems because there's binary blobs everywhere, that SUCKS.

          Comment


          • #6
            To me it didn't seem like SaucyJack was implying libv has to finish his work, although it would be nice though, and a huge slap in the face of ARM and all the board vendors.

            Everyone is to blame here, people keep buying boards with ARM's gpus, for which there are no open drivers and no real hope of ever getting open drivers, at least not while these gpus might be useful for anything else other than running glxgears.

            Board vendors are to blame because they sell in the millions and they have the weight to pressure ARM into providing an open driver, yet they don't care.

            And at last ARM is also to blame because they are hostile towards the idea of having an open driver.

            Comment


            • #7
              Originally posted by R00KIE View Post
              Board vendors are to blame because they sell in the millions and they have the weight to pressure ARM into providing an open driver, yet they don't care.
              Not sure about board vendors, they only buy one of the available socs. Chipset manufacturers however buy the mali gpu ip core. But they currently too, don't have that many options. Not sure if Broadcom are selling their VideoCore or Qualcom their Andreno as IP core to them, but I didn't think so. And Tegra too, is only build into socs by Nvidia. Vivante could be an option, but mesa support isn't mainlined yet. I hope that Imagination with PowerVR sees the light an release at least an open source vulkan driver for Linux/Mesa. Otherwise we have to wait until AMD gets their shit together and release and sell an ARM compatible Readon IP core. Hopefully that doesn't end up as a one soc manifacturer (mediatek) solution. But at least there we could get good open source gpu performance.

              Comment


              • #8
                Originally posted by PyroDevil View Post
                Not sure about board vendors, they only buy one of the available socs. Chipset manufacturers however buy the mali gpu ip core. But they currently too, don't have that many options.
                Who specs the SoC? The foundries only manufacture what their clients send them. SBC vendors and mobile phone vendors/manufacturers _are_ to blame. They have enough weight to force ARM to provide open drivers. Here there is also enough blame to go around, everyone is doing their thing, coding their own drivers for ancient kernels and then throwing everything over the fence and just forget it. This has worked wonders, for the ones selling of course, users are left with bug ridden and insecure devices that can't be updated unless prepared to lose functionality for which the device was bought in the first place.

                Originally posted by timofonic View Post
                I would consider because Open Source drivers and a big brand on it, that pays developers instead having amateur projects like Linux-Sunxi that really lag behind in support in comparison. I really hate ARM systems because there's binary blobs everywhere, that SUCKS.
                The guys from Linux-Sunxi may be going slowly but at least they are doing more than what can be said of almost everyone else.

                Regarding Intel, it seems lately they have dropped the ball, just take a good look at the current skylake support, and that is something everyone is using now, I don't want to imagine how it will be for things more niche. There is also the matter of Intel using more and more blobs that have to be uploaded to the hardware for things to work, not to mention the code that runs in the "special" microcontroller embedded on the cpu that can take over the whole system without you having any say in it, it would be good to at least be able to audit that code.

                That said, if given the choice I would pick an Intel/x86 device every single time.

                Comment


                • #9
                  Funny all the hate for ARM SoC's while intel maintains a very closed second cpu on every main cpu.
                  Funny that a lot of subsystems in the linux kernel are developed by manufacturers != intel.
                  The biggest problem of ARM SoC's lagging in mainstream is that the CPU usually is well supported, but the linux kernel usually has years to go before infrastructure is available to support all the functionality in a SoC.
                  Samsung started the v4l2_m2m subsystem 7 or 8 years ago? It took 3 years before it was cleanly in the kernel and today we see the first out-of-the-box usage of gstreamer with MFC hardware decoding and encoding using the v4l2_m2m interface and DMAbuf...
                  How long did CEC take to finally get a part in the kernel?
                  f2fs was done like that fortunately, but the kernel infra structure is well established.
                  Even rpmb on emmc which already exists for 8 years or so, has only recently seen a kernel API to really access the emmc. And this was fully SPECed.
                  So give me an ARM anytime over an intel as a desktop. The arm probably uses less power than the secret second cpu in an intel CPU, and still performs better than an atom.
                  For my steam machine I am still limited to intel arch. No hurt there.

                  Comment


                  • #10
                    Originally posted by Ardje View Post
                    The biggest problem of ARM SoC's lagging in mainstream is that the CPU usually is well supported, but the linux kernel usually has years to go before infrastructure is available to support all the functionality in a SoC.
                    That's mainly because it's cheaper for them to just make them as out-of-tree hacks, then some of their developers tries to mainline them in their spare time or something (and fixes the inane shit that is OK in a out-of-tree hack but not in mainline).

                    Comment

                    Working...
                    X