Page 7 of 16 FirstFirst ... 56789 ... LastLast
Results 61 to 70 of 153

Thread: AMD's R300 Gallium3D Driver Is Looking Good For 2011

  1. #61
    Join Date
    Oct 2010
    Posts
    126

    Default

    Quote Originally Posted by marek
    Because the current GLSL compiler in Mesa rocks and really produces optimized code. There's ongoing work to pass every shader (ARB assembly ones and fixed-function ones) through the GLSL compiler to optimize them a bit (and mainly to simplify things for hw drivers), but it's way harder to optimize low-level code than high-level one.
    Then how come ARB shaders work much faster using r300classic? Can't the developers use the assembly compiler of r300c in r300g?

  2. #62
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by bridgman View Post
    The open source drivers are not multi-threaded AFAIK, so single-thread CPU power probably makes a big difference in the performance results. It would be great if the same CPU could be used across a series of benchmarks so that the driver/hardware differences could be isolated.
    "The open source drivers are not multi-threaded AFAIK" which is Very ODD Today if thats really the case, as NPTL(Native POSIX Thread Library)has been in since 2.6 started http://en.wikipedia.org/wiki/Native_...Thread_Library
    "NPTL has been part of Red Hat Enterprise Linux since version 3, and in the Linux kernel since version 2.6. It is now a fully integrated part of the GNU C Library.[citation needed]
    There exists a tracing tool for NPTL, called POSIX Thread Trace Tool (PTT). And an Open POSIX Test Suite (OPTS) was written for testing the NPTL library against the POSIX standard." ,not to mention there are several other optimized 3rd party threading libraries suitable for any such driver inclusion around too.

  3. #63
    Join Date
    Jan 2008
    Posts
    295

    Default

    It's not about the lack of a threading library. It's that drivers don't make use of threading. It's nod odd, it's the norm.

  4. #64
    Join Date
    Jan 2009
    Posts
    598

    Default

    Quote Originally Posted by glxextxexlg View Post
    Then how come ARB shaders work much faster using r300classic?
    That's a real mystery to me.

    Quote Originally Posted by glxextxexlg View Post
    Can't the developers use the assembly compiler of r300c in r300g?
    Both the drivers have been sharing the same compiler backend since ever.

    To Michael and the others: The article only benchmarks r300g and st/mesa. The changes made to the r300 compiler are not visible in the graphs, because all the new compiler optimizations are applied to both r300g and r300c. A benchmark of both the drivers with several different versions of Mesa would better show the overall improvement. Yes, r300c is getting faster as well through the compiler work.

  5. #65
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,283

    Default

    Quote Originally Posted by popper View Post
    "The open source drivers are not multi-threaded AFAIK" which is Very ODD Today if thats really the case, as NPTL(Native POSIX Thread Library)has been in since 2.6 started
    ???

    I don't think anyone is saying that the lack of a threading library is the issue. Someone actually has to do the design, implementation and testing work to make it happen, and once the work is done all of the developers and testers have to live with the additional debugging challenges. There are other tasks which need to be done first.

  6. #66
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by bridgman View Post
    ???

    I don't think anyone is saying that the lack of a threading library is the issue. Someone actually has to do the design, implementation and testing work to make it happen, and once the work is done all of the developers and testers have to live with the additional debugging challenges. There are other tasks which need to be done first.
    your implication was that the open drivers were some how at a disadvantage compared to 'closed drivers that are threaded' in todays generic multi threaded CPUs market today, but perhaps it was a misunderstanding and you didn't actually mean that, but that's how it came across on first reading, fair enough.

  7. #67
    Join Date
    Jan 2008
    Posts
    295

    Default

    I think he _is_ implying that the closed-source drivers are multithreaded, and as such the open source driver are at a disadvantage.

    I don't have any clue what you're confused about, or how that confusion could lead to your post about NTPL being around for years.

  8. #68
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,283

    Default

    I did mean that to a certain extent, but mostly relating to making benchmarks more meaningful for Phoronix readers.

    The open drivers probably are at a disadvantage compared to the closed drivers as a consequence of being single threaded, but implementing multithreading is not a trivial task and the developer time is probably better spent on the development work that is being done today. Six months from now, who knows ?

    Completing the move to the Gallium3D architecture needs to happen first, along with phasing out UMS other than for legacy distros, so that only one code base needs to be reworked. In the short term, adding support for the performance-related hardware features like tiling provides more end-user benefit relative to developer effort than multithreading, at least for typical end-user systems.

    The important thing is that in a single threaded implementation the single-core CPU performance is a significant contributor to benchmark results, and comparing results across different benchmark articles is hard to do unless the same CPU/memory subsystem is used in both cases.

  9. #69
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by mattst88 View Post
    It's not about the lack of a threading library. It's that drivers don't make use of threading. It's not odd, it's the norm.
    dont you find that fact odd though? given virtually all dev's and end users today will be using at least a dual x86 CPU in 2010/11, but no matter, moving on....

  10. #70
    Join Date
    Jan 2008
    Posts
    295

    Default

    Quote Originally Posted by popper View Post
    dont you find that fact odd though? given virtually all dev's and end users today will be using at least a dual x86 CPU in 2010/11, but no matter, moving on....
    No, it's not odd or unexpected at all.

    Most programs are single threaded because in most cases, it's really hard to figure out how to split work efficiently across multiple CPUs. It's a huge outstanding research problem at the moment and probably will be for some time to come.

Tags for this Thread

Posting Permissions

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