Announcement

Collapse
No announcement yet.

DRM/KMS Driver Published For Snapdragon Graphics

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

  • #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; 06 July 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


            • #16
              the only things you can learn from an open driver are mostly worthless things since many are as SDK OS Level [WDDM/DRI/Gallium/COCOA/KMS/DRM/etc] standard or not compatible with you hardware design, for example follwing my previous T&L example:

              thing you can learn:
              1.) OMG they can do T&L in 1 cycle using 128bit precision, we do 4 32bit precision serialized operations 1 per cycle<-- hardware team hitting heads against walls trying to find a solution

              2.) LOL they use way higher memory addresses than we do, so they are wasting some cycle paging RAM unlike us <-- hardware team happy and drunk

              3.) check their OS level glue code they don't queue T&L requests like we do, instead the OS simply pass it to the hardware and expect it to work, that is why our hardware is more reliable in X app while it crash with their hardware that should be faster than ours <-- hardware/driver team opening champaigne

              and unlike urban myths this can as easily done with closed drivers as with open ones, using the exact the same method rub or nouveau team uses to reverse engineer their respective drivers

              Comment


              • #17
                Originally posted by jrch2k8 View Post
                the only things you can learn from an open driver are mostly worthless things since many are as SDK OS Level [WDDM/DRI/Gallium/COCOA/KMS/DRM/etc] standard or not compatible with you hardware design, for example follwing my previous T&L example:

                thing you can learn:
                1.) OMG they can do T&L in 1 cycle using 128bit precision, we do 4 32bit precision serialized operations 1 per cycle<-- hardware team hitting heads against walls trying to find a solution

                2.) LOL they use way higher memory addresses than we do, so they are wasting some cycle paging RAM unlike us <-- hardware team happy and drunk

                3.) check their OS level glue code they don't queue T&L requests like we do, instead the OS simply pass it to the hardware and expect it to work, that is why our hardware is more reliable in X app while it crash with their hardware that should be faster than ours <-- hardware/driver team opening champaigne

                and unlike urban myths this can as easily done with closed drivers as with open ones, using the exact the same method rub or nouveau team uses to reverse engineer their respective drivers
                I'd *guess* open src driver sheds some insight on what they were thinking for shader core, more so than on the fixed function parts of the pipeline.. not really to the point of open-src-driver == giving away the rtl, but maybe it gives some clues as to what the hw design team was prioritizing. All the same, it is really much too late in the design cycle for someone to come along any make a copy-cat gpu that is relavent (as opposed to coming out when said original GPU is already on generation N+2).

                Comment


                • #18
                  Originally posted by blackiwid View Post
                  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.
                  I guess I should have been more specific that the drivers should be OSS. I don't think there should be any proprietary software in the core of the system. User space software I don't have as much of a problem with provided it's not a turd like Flash.

                  Comment


                  • #19
                    Originally posted by robclark View Post
                    I'd *guess* open src driver sheds some insight on what they were thinking for shader core, more so than on the fixed function parts of the pipeline.. not really to the point of open-src-driver == giving away the rtl, but maybe it gives some clues as to what the hw design team was prioritizing. All the same, it is really much too late in the design cycle for someone to come along any make a copy-cat gpu that is relavent (as opposed to coming out when said original GPU is already on generation N+2).
                    exactly but even so is not possible to reverse the silicon seeing the compiler or the fixed paths like OP made believe, you can take hints at most but never make the conversion software->electronic diagram

                    Comment


                    • #20
                      Originally posted by liam View Post
                      Isn't the mali-400 driver finished?
                      Fully backed = supported by vendor.

                      Even if you read it as "fully baked", no, limare is not ready. I would call it ready when it can run any arbitrary GLES2 app and it's in a stable mesa release.

                      Comment

                      Working...
                      X