Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: Gallium3D's Softpipe Driver Now Runs Faster

  1. #21
    Join Date
    Oct 2008
    Posts
    151

    Default

    Quote Originally Posted by bridgman View Post
    A lot of effort has been made to simplify programming tools and lower the entry threshold for programming, allowing many more people to become effective programmers. (...) There has been some progress in this area (Linus doesn't code much these days) but we are probably only 30% of the way there.
    Well, it's not exactly people that passed "Visual Basic for dummies" that is passing code up to Linus... I'd say the greatest sin I see is insanity like "I don't want to use KDE or Gnome because they take up 20-50MB of memory" and instead you:

    1) Reinvent the wheel
    2) ...poorly
    3) Creating your own thing means everyone else must understand it all the way from the ground up, following no common patterns.
    4) Takes no advantage of shared libraries meaning you actually increase memory use if there's a hundred applications like yours.
    5) Your "light-weight" toolkit ends up taking on more and more crap eventually becoming what you wanted to avoid, only worse.
    6) Try optimizing out of trying to use shorts and ints and whatnot to save 2-4 bytes here and there in completely non-critical code
    7) Because your documentation sucks and noone knows what it really does, people copy-paste snippets that they know works. Spaghetti...

    What I have found is that there are very few cases where you're doing it "right" and still get unacceptable performance. Usually there's some other problem, for example that you put something stupid inside a loop or the wrong loop and the compiler didn't save your ass. Been there, done that - the difference between O(n) and O(n^2) is pretty high when n=50000. But I'd take 5 lines of library-calling code over 100 lines of DIY code any day.

    This kind of you see on both kinds of the stupid scale - those that are just so clueless they don't know what the library can do for them, and those that know it can and reject it because it's not "good enough". If so, get a patch upstream to the library and if you think that's too hard, the red blinkenlights should be on already.

  2. #22
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by Kjella View Post
    Well, it's not exactly people that passed "Visual Basic for dummies" that is passing code up to Linus... I'd say the greatest sin I see is insanity like "I don't want to use KDE or Gnome because they take up 20-50MB of memory" and instead you:

    1) Reinvent the wheel
    2) ...poorly
    3) Creating your own thing means everyone else must understand it all the way from the ground up, following no common patterns.
    4) Takes no advantage of shared libraries meaning you actually increase memory use if there's a hundred applications like yours.
    5) Your "light-weight" toolkit ends up taking on more and more crap eventually becoming what you wanted to avoid, only worse.
    6) Try optimizing out of trying to use shorts and ints and whatnot to save 2-4 bytes here and there in completely non-critical code
    7) Because your documentation sucks and noone knows what it really does, people copy-paste snippets that they know works. Spaghetti...

    What I have found is that there are very few cases where you're doing it "right" and still get unacceptable performance. Usually there's some other problem, for example that you put something stupid inside a loop or the wrong loop and the compiler didn't save your ass. Been there, done that - the difference between O(n) and O(n^2) is pretty high when n=50000. But I'd take 5 lines of library-calling code over 100 lines of DIY code any day.

    This kind of you see on both kinds of the stupid scale - those that are just so clueless they don't know what the library can do for them, and those that know it can and reject it because it's not "good enough". If so, get a patch upstream to the library and if you think that's too hard, the red blinkenlights should be on already.
    +++

    More people need to take this view I think.

    A bit of code consolidation would be a brilliant thing to have happen.

    There's so many projects out there re-inventing the wheel, and providing software that's almost useful, but is too broken to use on a daily basis.

  3. #23
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,567

    Default

    Well, you might say most modern opensource projects (including Linux kernel) originate from reinventing the wheel. Reinventing the wheel is nice and fine if you're a brilliant software designer. Most just are not.
    Last edited by nanonyme; 09-25-2009 at 05:24 AM.

  4. #24
    Join Date
    Jul 2009
    Posts
    47

    Default

    Quote Originally Posted by Kjella View Post
    But I'd take 5 lines of library-calling code over 100 lines of DIY code any day.
    What most people that try to critizise KDE/Gnome for their bloated libraries is that those libs are there and in that size the moment any application uses it. 20-40 Megs may be much if you're just using it to play KMahjong, but on my Setup I have 20-30 apps using that. If all those apps used their own code for file-viewing and saving configs and all that I wouldn't have any space left.

    Everybody talking to me about how "lightweight" Wxwidgets or whatever toolkit of the month they have is only uses one viewpoint: "My application is the only one ever getting used".

    That's why I like the way the LSB and QT and GTK have been going these last years: More and more functionality is going into the main libs and being standardized, thus getting more and more code shared. Sure it makes the main lib larger, but it shrinkens every other app using it.

    And the way I understand it, Gallium isn't much different. That's why I'm preparing for a shitstorm on Phoronix, because initial releases of Gallium WILL be slower and buggier than doing everything seperate for every driver in Mesa. But it will be the right thing.

  5. #25
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by fabiank22 View Post
    And the way I understand it, Gallium isn't much different. That's why I'm preparing for a shitstorm on Phoronix, because initial releases of Gallium WILL be slower and buggier than doing everything seperate for every driver in Mesa. But it will be the right thing.
    Heh... And, it'll serve for more than Mesa. Besides, if you want Larrabee, or any other modern GPU design, you have to do something along those lines.

    AMD has something VERY similar- just ask our resident AMD rep in the forums...

    NVida has their own sort of answer- and it's mostly the same story.


    It'll be a bit twitchy at first, much like Utah-GLX and then DRI that followed; but in the end, it'll be the right way and it'll all gel. In all truth, Gallium3D's something we've needed for a long time now.

  6. #26
    Join Date
    Oct 2008
    Location
    Sweden
    Posts
    983

    Default

    Quote Originally Posted by fabiank22 View Post
    And the way I understand it, Gallium isn't much different. That's why I'm preparing for a shitstorm on Phoronix, because initial releases of Gallium WILL be slower and buggier than doing everything seperate for every driver in Mesa. But it will be the right thing.
    I guess those of us with both too much time on our hands and an extremely large amount of patience could start the testing and bug filing right now, with the softpipe.

  7. #27
    Join Date
    Mar 2008
    Location
    Istanbul
    Posts
    134

    Default

    Does any one know how could I use/test this Gallium3D's Softpipe Driver? I am compiling from git trunk but I cannot 'use' this driver yet. (Using radeon r600 dri2 kms)

  8. #28
    Join Date
    Oct 2008
    Location
    Sweden
    Posts
    983

    Default

    Not sure about softpipe in general, but llvmpipe have instructions for building and running:
    http://cgit.freedesktop.org/mesa/mes...lvmpipe/README

Posting Permissions

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