Results 1 to 10 of 10

Thread: Open-Source ARM Mali Driver Update (Lima)

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,654

    Default Open-Source ARM Mali Driver Update (Lima)

    Phoronix: Open-Source ARM Mali Driver Update (Lima)

    This weekend at LinuxTag 2012, an update was shared concerning the state of the Lima driver project -- the initiative to create a reverse-engineered, open-source ARM Mali driver...

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

  2. #2
    Join Date
    Jan 2011
    Posts
    472

    Default

    Will the Vivaldi be using the Lima driver or using the proprietary X11 2D driver from ARM?

  3. #3
    Join Date
    Aug 2011
    Posts
    572

    Default

    Quote Originally Posted by e8hffff View Post
    Will the Vivaldi be using the Lima driver or using the proprietary X11 2D driver from ARM?
    I don't think they're gonna rely on Lima being ready on time, so for now, most likely the proprietary one (I think).

  4. #4
    Join Date
    Jul 2011
    Location
    florida usa
    Posts
    81

    Default

    were they going to ever focus on making a gallium driver for the mali 400? thats what im most interesdet in, mesa not too long ago gained support for android so it would be able to provide a very capable modile gl implementation

  5. #5
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    342

    Default

    Quote Originally Posted by benjamin545 View Post
    were they going to ever focus on making a gallium driver for the mali 400? thats what im most interesdet in, mesa not too long ago gained support for android so it would be able to provide a very capable modile gl implementation
    There will be no gallium driver for mali. Turns out that gallium is too intertwined with TGSI to be able to run the framework with ARMs binary shader compiler. We need the ability to swap around the ARM compiler and our own free compiler (current plan is that it will be TGSI based), so that we can compare them directly and extensively. This is the only sane way for us to get actual performance comparable to the closed driver. This means that we will be writing a "standard" mesa driver instead, which will give us the flexibility we need.

    About the timing, it depends, mostly on how much time i get to work on the project. We are doing this job in a structured way, and complete the tasks in a logical and efficient order. There is no point throwing halfarsed stuff into a mesa framework from afar while fundamental REing work is still ongoing. That's just stupid timewasting, and is simply a big and meaningless statement. I am personally quite sick of people who take huge shortcuts, leave tons of blanks, just to be able to pee against the tree, shout "I've done it!!!!!" and then run off to the next tree. That's sort of behaviour is just damaging free software.

    And please, look at the timeframe for this project, and then remember that this is all reverse engineering. Where were we 6 months ago? Where are we today?

  6. #6
    Join Date
    Jul 2011
    Location
    florida usa
    Posts
    81

    Default

    oh, so this is still in the initial RE phase, i thought this effort was to actualy create a finished product, at least thats what the phoronix articles have been billing it as.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •