Page 11 of 21 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 202

Thread: A Big Comparison Of The AMD Catalyst, Mesa & Gallium3D Drive

  1. #101
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by bridgman View Post
    The open source driver code seems pretty efficient though, which is why there is some head-scratching going on.
    ?? really?



    does this mean the catalyst team learn something from the OS team ?

  2. #102
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    511

    Default

    Bridgman, I am sure if you do not know where the bottlenecks are, you(and other developers) have suspects. Is it in kernelmode or usermode part of the stack?

  3. #103
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,451

    Default

    Quote Originally Posted by Qaridarium View Post
    does this mean the catalyst team learn something from the OS team ?
    Um... yes there's some head scratching going on (just like in the picture ) but the associated question is more along the lines of "the code in the open source driver looks pretty good, but it seems to run a lot slower than Catalyst and we don't know why".

  4. #104
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,451

    Default

    Quote Originally Posted by Drago View Post
    Bridgman, I am sure if you do not know where the bottlenecks are, you(and other developers) have suspects. Is it in kernelmode or usermode part of the stack?
    The problem is that so far the test results aren't supporting our initial suspicions. Going in I think most of us suspected that the bottlenecks were likely to be in the kernel driver (synchronization, memory mapping etc..) but test results seem to suggest that common mesa code in the usermode 3D driver is a bigger factor. There's a lot more testing required though, and there are conflicting views re: how to interpret the test results so far.

    Performance optimization is basically :

    - run some benchmarks & save the results
    repeat forever {
    - do some profiling
    - form a theory re: where the bottleneck is
    - change some code to test the theory
    - re-run the benchmarks to see if things go faster
    - (4 times out of 5) curse and discard the theory (or save as the basis for a more complex theory)
    - (1 time out of 5) make happy noises and get some sleep
    }

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

    Default

    Quote Originally Posted by bridgman View Post
    Um... yes there's some head scratching going on (just like in the picture ) but the associated question is more along the lines of "the code in the open source driver looks pretty good, but it seems to run a lot slower than Catalyst and we don't know why".
    o bad thats not so funny..

  6. #106
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by Qaridarium View Post
    o bad thats not so funny..
    Take heart Q, at least the poor performance isn't AMD specific but is a across all current solutions with FOSS drivers. It may mean that the greatest increase in performance may come from a joint effort to find the common cause.

  7. #107
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    511

    Default

    Does the Radeons offer debug instrumentarium, like the CPUs. Cache misses, instruction counting, pipeline stalls. Or bassicaly is there way to know that your shader compiler is bad, and thus resulting stalls on more SIMDs than needed. In general how you evaluate FOSS r600 shader compiler? Dismissing shader compiler as the main bottlenck, open spaces for more agressive CPU micro optimizations, e.g: branch prediction hints, preventing CPU cache trashing etc. Well that will break portability to other platforms, but I am sure fglrx is full of that.

  8. #108
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,451

    Default

    Quote Originally Posted by Qaridarium View Post
    o bad thats not so funny..
    Yeah, I would have been happier if it was the other way

    Part of the problem is that profiling only tells you what the CPU is doing, not what the GPU is doing.

    Drago, there are some hardware bits that can help but they're mostly aimed at getting the most out of the GPU once core driver isses are worked out, don't think they will help much here but we are going to look at those as well. Right now the open source driver hacked to not run anything on the GPU is still slower than fglrx doing full rendering (even on a single CPU core, apparently).

    The "good" news (such as it is) is that this means there is a bunch of useful work that can be done before getting into the nasties of performance tuning on a pile of asynchronous engines (CPU execution, CPU cache flusher thingy, command processor, graphics pipe, shader core, vertex fetcher, texture fetchers/filters, GPU memory controller, GPU cache flusher thingy etc...).

  9. #109
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    If most of this work is in core Mesa (as I understood it, perhaps incorrectly), then all drivers will profit from this work?

  10. #110
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    511

    Default

    Quote Originally Posted by pingufunkybeat View Post
    If most of this work is in core Mesa (as I understood it, perhaps incorrectly), then all drivers will profit from this work?
    The focus is primarily on Gallium3D, so no intel there. An they are the second biggest contributor to Mesa. VMware being the first.

Posting Permissions

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