Announcement

Collapse
No announcement yet.

Which are the main reasons of the poor performance of open graphics driver?

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

  • Which are the main reasons of the poor performance of open graphics driver?

    Is it mainly a matter of too many layer?
    Or algorithms don't sufficiently flexible to be able to use at best the hardware?
    Or both?

    Note:
    I speak for situations when the documentation is present as happen on Intel (at least on most part) and partially on Amd.

  • fhuberts
    replied
    shader compiler

    Originally posted by bridgman View Post
    Drivers for the 6xx and higher generations are moving towards the same point, although they'll probably need a shader compiler revamp before they get there.
    How about ripping the shader compiler from fglrx then?
    And I mean ripping: it doesn't need to work, just let the open source devs look at it and make it work...

    trying to think out of the box...

    Leave a comment:


  • alelinuxbsd
    replied
    Thanks i missed to read that article before.
    I hope that at least with the new Amd Apu that situation change given that proprietary Amd driver (apart bugs) aren't available forever and perhaps the change on the Gpu on Apu could be more limited(1) and this should make more easy and fast a code optimization even on open source driver.
    Put aside the remain problem of support of new standard, another issue given that involve other project.

    (1) For example on the Intel Ivy Bridge will be support for new standard but the hardware architecture probably will don't change much, if the same thing will happen for the future Apu from Amd ...
    Perhaps isn't a good wish, given that a lower hardware innovation reduces even the possible maximum performance, but if this could help the open source driver to be ready faster and with good performance, i'm more then happy the same.

    Leave a comment:


  • bridgman
    replied
    On the ATI/AMD side we only started serious code sharing relatively recently -- the Sep 2007 driver was the first time that real benefits were visible although work started a couple of years before that. Remember that we focused on open source drivers for Linux until ~2002 when we started working with proprietary drivers as a consequence of bringing FireGL into ATI, and that by 2007 we had re-started the open source support efforts.

    Before looking for a single big reason why the open source drivers are slow relative to proprietary it's probably worth taking a fresh look at Michael's last benchmark report :

    http://www.phoronix.com/scan.php?pag...our_r300&num=1

    The delta between open and closed drivers has dropped to what can be explained by "a few hundred developer years of optimization" on the pre-6xx side. Drivers for the 6xx and higher generations are moving towards the same point, although they'll probably need a shader compiler revamp before they get there. The 3xx-5xx driver stacks had a fairly sophisticated shader compiler, while the shader compiler for 6xx and higher is not at the same level yet.

    The secret to driver performance is not that different from the secret to a good English lawn - "just seed and roll for 150 years"
    Last edited by bridgman; 09-07-2011, 04:11 PM.

    Leave a comment:


  • alelinuxbsd
    replied
    Originally posted by darkbasic View Post
    Yes, but 90% of the code is shared with the windows driver.
    Even on Amd or only on nVidia?
    Given that the main part of the code is shared why amd is always so behind nVidia?

    And about the other hypothesisf the distance on the open source driver?
    Was i right or wrong?

    Generally i think that once is known the main problems is possible move on, so perhaps could be helpful known the reasons behind this huge lack of performance.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by alelinuxbsd View Post
    The group that work on linux driver usually are limited even on proprietary driver.
    Yes, but 90% of the code is shared with the windows driver.

    Leave a comment:


  • alelinuxbsd
    replied
    Originally posted by marek View Post
    A lack of manpower.
    How is possible?
    Generally important open project have many collaboration around the world.Even more respect proprietary software.
    Anyway often proprietary driver on linux aren't good (for bugs), only nVidia make a little better, because they have few interest on Linux.
    The group that work on linux driver usually are limited even on proprietary driver.
    Other hypothesis:
    - argument too difficult so is a big limit at partecipation of a certain level?
    - slow decision-making in the direction (feautures, etc) to be taken during developing?
    - development process does not efficiently structured to avoid the task carried out by a developer does not block the work of another if it isn't concluded? (This problem for example happen for Gimp while after the 2.8 release perhaps will be solved).

    Leave a comment:


  • Plombo
    replied
    Originally posted by marek View Post
    A lack of manpower.
    This. We have easily less than a tenth of the number of developers that work on the proprietary drivers.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by Qaridarium View Post
    benchmarked on obsolete software like quake3 LOL...
    No, benchmarked on shader intensive games like xonotic.

    Leave a comment:


  • marek
    replied
    A lack of manpower.

    Leave a comment:

Working...
X