Announcement

Collapse
No announcement yet.

DRM/KMS Driver Published For Snapdragon Graphics

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

  • DRM/KMS Driver Published For Snapdragon Graphics

    Phoronix: DRM/KMS Driver Published For Snapdragon Graphics

    Rob Clark has expanded his Freedreno efforts from just being a reverse-engineered user-space (Gallium3D) graphics driver for Qualcomm's Adreno/Snapdragon hardware. Rob has now written his own DRM/KMS kernel driver for dealing with the Snapdragon graphics hardware...

    http://www.phoronix.com/vr.php?view=MTQwNDM

  • #2
    Ok, so what is the fastest ARM hardware with fully backed drivers and can boot a standard distro instead of Google crap like Android or ChromeOS?

    Comment


    • #3
      Originally posted by Kivada View Post
      Ok, so what is the fastest ARM hardware with fully backed drivers and can boot a standard distro instead of Google crap like Android or ChromeOS?
      I would very much like to know this as well, since there is more and more news of these improvements but almost no common use for them. I know it's just around the corner, but it would be nice to know what commercially available products to expect a good experience with.

      Comment


      • #4
        Originally posted by scionicspectre View Post
        I would very much like to know this as well, since there is more and more news of these improvements but almost no common use for them. I know it's just around the corner, but it would be nice to know what commercially available products to expect a good experience with.
        Android. Google Chrome....

        Companies wont pick FLOSS drivers UNLESS they show real benefits.

        Comment


        • #5
          Originally posted by Kivada View Post
          Ok, so what is the fastest ARM hardware with fully backed drivers and can boot a standard distro instead of Google crap like Android or ChromeOS?
          you did not specialy ask about "free drivers" only about working... fast... that makes the answer more difficult... I guess It would be to use or wait for mir or waylands android-driver wrapper and use this. And because neighter mir is productive-ready nor wayland and there are as far I know no non-free mesa drivers for X for android that is the one site of the answer.

          If you want a working system now I think this adreano drivers here is the best you can get, correct me if I am wrong and there are some propriatary drivers that are better. you can get such hardware as example with a LG Nexus 4, and install on it as example a fedora:

          http://www.phoronix.com/scan.php?pag...tem&px=MTM4NDY

          or you could get a board or something with that gpu and use a normal arm-installer of a distro I guess.

          Comment


          • #6
            Nothing has fully backed drivers if you include the 3d chip.

            Comment


            • #7
              If I am not mistaken, the best chance to use ARM hardware would be to use one of the upcoming Ubuntu releases with XMir/Mir and Android drivers.

              Comment


              • #8
                Originally posted by d2kx View Post
                If I am not mistaken, the best chance to use ARM hardware would be to use one of the upcoming Ubuntu releases with XMir/Mir and Android drivers.
                although that doesn't help too much anyone who wants to run (real) linux ;-)

                Comment


                • #9
                  Best ARM Linux GPU

                  If you want decent GPU support under ARM Linux, the Nexus 4 plus Rob's driver is one of the best bets right now, as has already been mentioned but thats not 'official'.

                  The only official and fully supported ARM Linux drivers I'm aware of are Nvidia's for their Kayla platform but I'd imagine it will be kept closed.

                  For good FLOSS drivers w/ 3D accel there are the Lima drivers which have been shown running Q3 at full speed but apparently ARM (who own the Mali tech) don't approve, prob as they know the Lima drivers are shaping up to be better than their closed drivers. Also, I doubt Mali has enough balls to be certified for GLES 3, which Nvidia will be more than good enough for.

                  EDIT

                  Oh yeah, there is also the Vivante GPUs as used in imx.6 socs - I've heard they've got a working, fully featured driver too but I don't know the details.

                  EDIT 2

                  If you want a Mali device, most of the 'Google TV' mini Android computers use these GPUs and you can easily buy one for less than $50. Search for Picuntu and its offshoot distro home://io , which has the Lima drivers included.
                  Last edited by danboid; 07-06-2013, 12:27 PM.

                  Comment


                  • #10
                    Thanks, danboid, for answering the question clearly to the best of your knowledge, without nitpicking the question itself. I'll have to look into what Picuntu can do, since every guide I've seen requires a lot of fidgeting to get the drivers up and running, almost always with a modified graphics stack.

                    Comment


                    • #11
                      Freedreno

                      From what I can tell, the best would still be Qualcomm/Freedreno.

                      Rob CLarke might be doing this as a side project but he has gotten quite far. There is bootable fedora with 3d (including a few hacks that have not been upstreamed yet) for A2xx devices (eg HP Touchpad) and there is also a bootable Fedora with (probably also with hacks that have not been upstreamed..) for A3xx (Nexus 4) devices.

                      None of these use the Android stack, but standard Fedora Linux.

                      I would expect this to be mainlined very soon and as Qualcomm is a major player in the embedded market, by Fedora 20 I wouldn't be surprised if say 40% of the Arm market was not supported to atleast some extent.

                      (Major players are Qualcomm/Adreno, Arm/Mali which is also being reversed engineered from what I have read quite successfully, nVidia/Tegra, which will probably remain troublesome and PowerVR which is a nightmare.)

                      Question for a developer? since iirc, Adreno is a fork from (mobile) Radeon, can some of the newer AMD support be leveraged or has it diverged too significantly/independently for that to be of any use?

                      Comment


                      • #12
                        [QUOTE=curaga;340997]Nothing has fully backed drivers if you include the 3d chip.[/QUOTE

                        Isn't the mali-400 driver finished?

                        [QUOTE=danboid;341037}
                        For good FLOSS drivers w/ 3D accel there are the Lima drivers which have been shown running Q3 at full speed but apparently ARM (who own the Mali tech) don't approve, prob as they know the Lima drivers are shaping up to be better than their closed drivers. Also, I doubt Mali has enough balls to be certified for GLES 3, which Nvidia will be more than good enough for.[/QUOTE]

                        Why would ARM care if the open drivers are better? They don't make the hardware and I'd have to think they'd love for someone to provide better drivers than "they've" written especially if they're free.
                        The only issue that I can imagine is licensing.
                        Last edited by liam; 07-06-2013, 03:21 PM.

                        Comment


                        • #13
                          if there is an open source driver for your hardware that you dont manufacture yourself, but liscense out to others, it makes unauthorized implementations of your hardware (think china's lack of copywrite laws and enforcment) virtualy trivial. its been done with MIPS at least twice, lexra was a perfectly legal copy of mips (except for the 4 patented opts) and could often be used with MIPS code with no problem, china had longsoon whitch up until not to long ago did not pay royalties to MIPS. for CPU arch like that it is trivial to copy a cpu architecture as far as software goes. for GPU's you need the driver to support whatever little differences your hardware has, if you have a locked down closed driver, it will only support the specific versions of your chips you choose for it to support, you would have to mimic a particular chip exactly and you would be limited to whatever the oficial chip designer creates. you could not make a better chip because you would first have to wait for the official designer to make something bettor for you to copy, and it would be hard to copy exactly.

                          with an open source driver you would just copy the majority of the design and make specific imporvements or differences you want and then modify the open driver to support it. you could easily make a better product than the official designer. a good example would be, the Mali chipset is only used in mobile applications, but lets say you wanted to make a discrete graphics card to compete with mvida and amd. you could start start with a mali design, and swithc out parts that would be inefective for discrete designes with new design, and replicate it many times in one chip to create a fairly powerfull discrete card. you would then just modify the open source mali driver to support it. ya it would be a lot of work, but it may not be as much work as starting from scratch, especialy if mali was designed to be easily modifiable for a discrete card purpose from the beginning posiibly for there own future expansion.

                          basicaly to sum it up, if you control the software driver, you control the hardware.

                          Comment


                          • #14
                            Originally posted by benjamin545 View Post
                            if there is an open source driver for your hardware that you dont manufacture yourself, but liscense out to others, it makes unauthorized implementations of your hardware (think china's lack of copywrite laws and enforcment) virtualy trivial. its been done with MIPS at least twice, lexra was a perfectly legal copy of mips (except for the 4 patented opts) and could often be used with MIPS code with no problem, china had longsoon whitch up until not to long ago did not pay royalties to MIPS. for CPU arch like that it is trivial to copy a cpu architecture as far as software goes. for GPU's you need the driver to support whatever little differences your hardware has, if you have a locked down closed driver, it will only support the specific versions of your chips you choose for it to support, you would have to mimic a particular chip exactly and you would be limited to whatever the oficial chip designer creates. you could not make a better chip because you would first have to wait for the official designer to make something bettor for you to copy, and it would be hard to copy exactly.

                            with an open source driver you would just copy the majority of the design and make specific imporvements or differences you want and then modify the open driver to support it. you could easily make a better product than the official designer. a good example would be, the Mali chipset is only used in mobile applications, but lets say you wanted to make a discrete graphics card to compete with mvida and amd. you could start start with a mali design, and swithc out parts that would be inefective for discrete designes with new design, and replicate it many times in one chip to create a fairly powerfull discrete card. you would then just modify the open source mali driver to support it. ya it would be a lot of work, but it may not be as much work as starting from scratch, especialy if mali was designed to be easily modifiable for a discrete card purpose from the beginning posiibly for there own future expansion.

                            basicaly to sum it up, if you control the software driver, you control the hardware.
                            I seriously doubt that the "hardware reimplementation" of an said device starting from its software drivers can be anything else than an clean room reverse engineering.

                            Your call is just an silly (but standard) excuse from the hardware people.

                            The reality is that the open-source support open new windows of utility for your said device.

                            An stupid example:

                            Now you can buy an 10" ARM netbook with $100. Capable to play media (using hardware en/decoding), to show web rich content including flash. BUT, it use Android, which is just a toy of grown people.

                            Open the drivers stack, specially the video and video processing (as in ie hardware MP4 decoding) and there you will have hundreds of Linux distributions on it.

                            And Linux can do things for Office and you can really do something seriously with this tinny netbook. AND your sales will grow 10,000% while after some time even the full fledged Windows (13?) will come to ARM platform and your sales will grow 1,000,000,000%.

                            Comment


                            • #15
                              to resume this is actually entirely wrong.

                              you sportly assume you know what the hardware does internally through the software interface and that somehow you can reverse engineer the hardware from that which is utterly impossible.

                              hardware and very much so GPU work using roundrobin question-answer-datapack protocol, for example:

                              Set on T&L on the GPU[require 128bit]<-- made up fast example, check AMD gpu docs for example to certify this if you like or any other consumer devices hardware SDK that you wish for that matter
                              1.) prepare data [0x33]<--initialization signal[344]<--open data stream for reception[334ff54554fadda77665432345]<--scene obbject datastream[ff1]<--close stream
                              2.) set datastream to adress 0x233234
                              3.) if return[0xffa]<-- success
                              4.) send[0x12e]<--commit and process stream
                              5.) if return[0xff+different from a] <-- not success check hardware spec for error datasheet
                              6.) send[0xaa4]<--reset stream to try again

                              as you can see is impossible to figure out how exactly the GPU silicon handles T&L from this and in fact you can have 2 different GPU from the same provider that process T&L exactly this way and 1 model process it using fixed path block while the newer one emulate the block in shaders entirely automatic inside the silicon.

                              the only possible way to see how the hardware do things from software is using FPGA which nobody uses ever in consumer hardware due to extreme costs and it does use a completely different set of language and tools unlike anything you ever use.

                              to reverse engineer a piece of hardware you need an electronic diagram and the logic diagrams for each unit block, otherwise is extremely difficult and very very close to impossible[or at least waaaay expensier than just do your own design or license it from a 3rd party]

                              in the case of china and MIPS it was the later case.

                              i repeat for any newcomer that could get misinformed, is plainly absolutely impposible to reverse engineer a piece of hardware from software unless you are working with FPGA[is nothing near easy tho]

                              Comment

                              Working...
                              X