Announcement

Collapse
No announcement yet.

DRM/KMS Driver Published For Snapdragon Graphics

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

  • phoronix
    started a topic DRM/KMS Driver Published For Snapdragon Graphics

    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

  • liam
    replied
    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.

    Leave a comment:


  • curaga
    replied
    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.

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:


  • Kivada
    replied
    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.

    Leave a comment:


  • robclark
    replied
    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).

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:


  • jrch2k8
    replied
    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]

    Leave a comment:


  • LuckyCyborg
    replied
    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%.

    Leave a comment:


  • benjamin545
    replied
    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.

    Leave a comment:

Working...
X