Announcement

Collapse
No announcement yet.

"Mega Drivers" Being Proposed For A Faster Mesa

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

  • #31
    Originally posted by marek View Post
    Well, if you wanted all driver components to be in a single repository, that's not gonna happen. The kernel driver has to stay in the kernel and the mesa driver has to stay in Mesa, because the interface is the simplest and changes the least at the kernel<->mesa boundary. (BTW radeon gallium drivers don't use libdrm as the middle layer between the kernel and Mesa)
    Did i state that i needed _all_ components of _all_ drivers in driver specific repositories? I most certainly didn't. But i do believe that infrastructure (which is what mesa is) should try to encompass the needs of both users and driver developers as much as possible. Otherwise infrastructure fails.

    Look at Gallium versus Intel. What did gallium do wrong that intel couldn't use more bits of it? Or is intel just doing NIH as a rule?

    Originally posted by marek View Post
    All things that have to stay in Mesa should better be in one big blob to take advantage of link-time optimizations.
    This is all good and well, until someone else (who isn't called libv or who doesn't work for The Devil^W^WMark Shuttleworth^W^WCanonical or Microsoft^WNovell^WSuSE) finds another reason as to why this is not a move forward. And then all of this gets reverted again, and who knows how many "shortcuts" will have been made in the meantime, shortcuts which are much harder to undo than this build time change.

    Originally posted by marek View Post
    And one more thing: upstream only cares about upstream.
    How is this a reply to my previous statement?

    Are you stating that Mesa shouldn't care about users or driver developers? That it must have everyone marching in line, disallowing other ideas or free thought, and that it never ever should strive to deliver what its users really need or want?

    If anything only exists for sustaining itself, it has lost all use or relevance. So keep up that thinking with mesa, soon, with Surfaceflinger and binary graphics drivers, upstream mesa will end up having made itself superfluous.

    Comment


    • #32
      What anholt is only now stating, is that LTO brings a 6% gain in the single most CPU intensive test he could find... The across the board gains will be a lot lower.

      Comment


      • #33
        Originally posted by libv View Post
        What anholt is only now stating, is that LTO brings a 6% gain in the single most CPU intensive test he could find... The across the board gains will be a lot lower.
        1.) well i agree with you on the intel case and if they were waiting to see gallium progress i think AMD showed is good enough since in many generations is rivaling their FLGRX and is beyond 50% compared to win7/8 drivers. Maybe they should start taking iLO/LLVM more seriously.

        2.) maybe "Mega Drivers" is not exactly a priority right now[i think was your point since at some point got very melodramatic from my PoV] but maybe "Mega Mesa" could be a better approach first?, meaning gets as much mesa shared code into one LTO friendly blob

        3.) maybe mesa can gain something nuking all those dead drivers+infrastucture for mesa 10? i mean SiS, Via, r128, openchrome and related corpses of the dark ages[keep them in 9 release for the 3 guys that needed it]

        4.) maybe after reaching Opengl 3.3 stable in Intel/AMD/nouveau focus 1 whole major release in stabilization,threading, gallium[intel case] and vectorization, this should help a lot in cpu bound scenarios specially in AMD FX and Ivy bridge+ processors

        5.) maybe take part of the vadim and tstellar work on llvm and make mesa glsl use it to generate LLVM IR and let later to LLVM to decide the backend depending the GPU? this could help to optimize once and use all as much as possible

        just some ideas

        Comment

        Working...
        X