Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: The Grinch That Stole The Radeon Gallium3D Performance?

  1. #11
    Join Date
    Oct 2008
    Posts
    3,248

    Default

    Quote Originally Posted by FireBurn View Post
    If someone can confirm that I'll update my post
    I've for sure done it with LD_LIBRARY_PATH=X LIBGL_DRIVERS_PATH=X

    I'm not sure if both of those are necessary - i think it's just one of them.

  2. #12
    Join Date
    Jun 2010
    Location
    Brno, Czech Republic
    Posts
    25

    Default

    Quote Originally Posted by smitty3268 View Post
    I've for sure done it with LD_LIBRARY_PATH=X LIBGL_DRIVERS_PATH=X

    I'm not sure if both of those are necessary - i think it's just one of them.
    LIBGL_DRIVERS_PATH=/path/to/mesa/lib/gallium is always needed, this is the location where your r300_dri.so is.
    LD_LIBRARY_PATH=/path/to/mesa/lib is needed for mesa's libGL.so, however usually your system stock libGL.so is sufficient.

  3. #13
    Join Date
    Jun 2010
    Posts
    13

    Default

    This analysis confirms that performance is an important issue the gallium3d drivers need to address. Gallium 3d developers have implemented more and more features to their drivers and that is great, but sometimes I think that this has been at the cost of performance (which is far behind proprietary drivers).
    Also, I am curious of how much attention do older hardware drivers get. Maybe this is not an issue for some, but here in third world countries we run a lot of older hw in our machines.
    Anyway I am confident that these performance issue will be resolved. =)



    Merry Christmas.

  4. #14

    Default

    Quote Originally Posted by zwastik View Post
    This analysis confirms that performance is an important issue the gallium3d drivers need to address. Gallium 3d developers have implemented more and more features to their drivers and that is great, but sometimes I think that this has been at the cost of performance (which is far behind proprietary drivers).
    Also, I am curious of how much attention do older hardware drivers get. Maybe this is not an issue for some, but here in third world countries we run a lot of older hw in our machines.
    Anyway I am confident that these performance issue will be resolved. =)

    Merry Christmas.
    https://twitter.com/#!/michaellarabe...60220548927488
    https://twitter.com/#!/michaellarabe...62664813146112

  5. #15
    Join Date
    Jun 2011
    Posts
    79

    Default

    Quote Originally Posted by FireBurn View Post
    Sigh

    Phoronix - where articles ARE the bug reports
    Phoronix, where they post better articles than just reprints of ads.

  6. #16
    Join Date
    May 2010
    Posts
    128

    Default

    Quote Originally Posted by FireBurn View Post
    Sigh

    Phoronix - where articles ARE the bug reports
    Bug reports that generate revenue maintain the tester's income and interest, as well as awareness in the community. In the graphics community a lot of the developers read Phoronix so the message isn't being lost (as evidence, it looks like they already found this regression).

    Kudos Michael.

  7. #17
    Join Date
    Apr 2011
    Posts
    405

    Default

    Quote Originally Posted by Michael View Post
    The regressed commits should be published on Christmas.
    Don't you actually mean this is an R300g issue, which does not include support for any RadeonHD models?

    I notice you didn't check out r600g, which does support all the RadeonHD models.

    Also worth a mention but not really a big issue is r100 and r200, but those cards are so old that I doubt anyone using them is running anything too stressful on the GPU.

  8. #18
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,578

    Default

    Quote Originally Posted by zwastik View Post
    Gallium 3d developers have implemented more and more features to their drivers and that is great, but sometimes I think that this has been at the cost of performance (which is far behind proprietary drivers).
    I don't think the developers knowingly implement anything which hurts performance, except in cases where frequently used cases are sped up at the expense of a less common case which gets slowed down.

    It's more likely that the developers implemented a new feature, application runtime logic saw the new feature and used it, but for that particular application/card/driver combination using the new feature is actually slower than running without the feature. Game developers do often put heuristics in which help to choose the right code paths depending on GPU/CPU/driver but they tend to be backward looking and have trouble dealing with a driver that is constantly evolving.

    Quote Originally Posted by zwastik View Post
    Also, I am curious of how much attention do older hardware drivers get. Maybe this is not an issue for some, but here in third world countries we run a lot of older hw in our machines.
    Since open source developers often start as users who "get fed up and decide to take matters into their own hands" I imagine you will see more developers appearing in those areas as well. Open source projects tend to be "self correcting" that way, although the high learning curve for GPU drivers does make it harder for new developers to step in as existing developers move onto other projects.

  10. #20
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    138

    Default

    Just export LIBGL_DRIVERS_PATH=/path/to/mesa-source/lib and then export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$LIBGL_DRIVERS_PA TH. There's no need for LD_PRELOAD. Then, you don't have to 'make install'.

Posting Permissions

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