Announcement

Collapse
No announcement yet.

DRM/KMS Driver Published For Snapdragon Graphics

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

  • #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


            • #21
              Originally posted by curaga View Post
              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.
              I'm not sure being in mesa is necessary but OK.
              My understanding was that it ran doom 3 really well. Given that is an old game maybe running it doesn't mean you can expect the driver to run an arbitrary game. I assumed that it did mean that, more or less.

              Comment

              Working...
              X