Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 35

Thread: AMD Catalyst vs. Linux 3.7 + Mesa 9.1-devel Gallium3D Performance

  1. #21
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by bobwya View Post
    I applaud the efforts that have been made with the radeon driver. It came from nothing - to the offer good stability and a good subset of the OpenGL requirements for modern 3D gaming. But last time I tested it on my laptop with a **real** game (S.T.A.L.K.E.R. : SOC via Wine) I got something like 6 FPS (Catalyst gives more like 30 FPS). The lack of full shadows isn't too noticeable - but the lamentable framerate is...

    Since I have a (very recent!!) legacy 4650M I guess most distros are gradually going to stop supporting it (my ARCH and Gentoo installs might limp on longer than the likes of Ubuntu - which xorg-server updates are the killer).

    I only have an AMD GPU in my laptop because Nvidia had nothing decent when I bought it. While the Catalyst driver was very slowly getting better over the years - I'm now stuck on some stupid legacy driver (limiting xorg-server and kernel updates).

    Trouble is I can't help looking at my truly ancient desktop Geforce 8800GTX with the bleeding edge 310.xx Nvidia beta driver - working like a champ and playing Black Mesa Source (via Wine) rather well!
    This is why I use Nvidia ... for now.. I hope.
    In fact, when I got HD4670 back in days to use opensource driver, I had 5 FPS in old version of OpenArena.. Now it *would* run @ 90 fps.

    The problem is that STALKER uses DX features that are not implemented in MESA yet, and it causes massive slowdowns. Absence of shadows is one of the indices.

  2. #22
    Join Date
    Jan 2009
    Posts
    615

    Default

    Quote Originally Posted by ilyes View Post
    If TTM is the culprit, why isn't there any patches already (4 years!) for addressing the buffers migration issue?
    The reason is simple - there is a lack of manpower. I myself won't have time to do anything big until February.

    I think the issue with TTM was there all long, we just didn't know it has such an impact. Since we started enforcing VRAM buffer placements, we've seen both great improvements (because of faster access to VRAM) and terrible regressions in perfomance (because of TTM when we start running out of memory).
    Last edited by marek; 11-27-2012 at 08:27 PM.

  3. #23
    Join Date
    Nov 2012
    Posts
    3

    Default

    Hi,

    Quote Originally Posted by bridgman View Post
    I expect the performance gap is caused by a dozen or more design differences, not one. Just a few off the top of my head :

    - tiling (mostly done AFAIK)
    - hyper-z (started)
    - shader compiler (WIP)
    - threading (command submission is in separate thread on r300g, not sure about r600g)
    - memory manager heuristics (this is what would probably help with buffer migration)
    - adaptive load balancing
    - adaptive memory reconfiguration

    BTW I don't think Marek is saying "we've known this for 4 years", I think he's saying "I just looked recently and the problem with these specific applications seems to be buffer migration".

    If the developers believed that one single issue was responsible for most of the performance differences then I think it's pretty safe to assume they would be all over it, but I don't think that is the case.

    Some apps (typically the very slowest) may have one single issue that contributes most of the slowdown RELATIVE TO OTHER APPLICATIONS but that's not the same as saying one single issue contributes to most of the performance gap between the open source stack and the Catalyst stack.
    All I'm saying is: Likely a bunch of different applications (like in Michael's benchmark, or a subset of them) exhibiting the same performance gap *factor* would likely mean a common root cause. This would be a constant and systematic driver behavior.

    I might be wrong!

    Quote Originally Posted by bridgman View Post
    Some apps (typically the very slowest) may have one single issue that contributes most of the slowdown RELATIVE TO OTHER APPLICATIONS but that's not the same as saying one single issue contributes to most of the performance gap between the open source stack and the Catalyst stack.
    Yes, this is what benchmarking is all about. The goal is to exercise the stack and detect isolated vs. generalized performance issues.

    Quote Originally Posted by bridgman View Post
    - tiling (mostly done AFAIK)
    - hyper-z (started)
    - shader compiler (WIP)
    - threading (command submission is in separate thread on r300g, not sure about r600g)
    - memory manager heuristics (this is what would probably help with buffer migration)
    - adaptive load balancing
    - adaptive memory reconfiguration
    Would love to see all these featured in the kernel/mesa!

    Regards,
    -Ilyes

  4. #24
    Join Date
    Nov 2012
    Posts
    3

    Default

    Hi Marek,

    Quote Originally Posted by marek View Post
    The reason is simple - there is a lack of manpower. I myself won't have time to do anything big until February.

    I think the issue with TTM was there all long, we just didn't know it has such an impact. Since we started enforcing VRAM buffer placements, we've seen both great improvements (because of faster access to VRAM) and terrible regressions in perfomance (because of TTM when we start running out of memory).
    Is there any way to trace TTM's allocations and visualize the dynamics (such as via a tool, in real-time)?

    -Ilyes

  5. #25
    Join Date
    May 2011
    Posts
    54

    Default

    Quote Originally Posted by marek View Post
    The reason is simple - there is a lack of manpower. I myself won't have time to do anything big until February.

    I think the issue with TTM was there all long, we just didn't know it has such an impact. Since we started enforcing VRAM buffer placements, we've seen both great improvements (because of faster access to VRAM) and terrible regressions in perfomance (because of TTM when we start running out of memory).
    We have bug in bugzilla or thread in maillist?

  6. #26
    Join Date
    Jan 2009
    Posts
    615

    Default

    Quote Originally Posted by ilyes View Post
    Is there any way to trace TTM's allocations and visualize the dynamics (such as via a tool, in real-time)?
    No, there isn't.

    Quote Originally Posted by stalkerg View Post
    We have bug in bugzilla or thread in maillist?
    We have bug reports that some apps are too slow.

  7. #27
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by ilyes View Post
    Would love to see all these featured in the kernel/mesa!
    It's a community developed driver, more contributors would be welcomed.

  8. #28
    Join Date
    Jul 2010
    Posts
    448

    Default

    Quote Originally Posted by stalkerg View Post
    We have bug in bugzilla or thread in maillist?
    I am following the mesa-dev list. Jerome has tried a few heuristics without positive results:
    http://lists.freedesktop.org/archive...er/029834.html

    The issue with radeon performance is clearly a serious lack of developers imho. The AMD guys are only doing basic stuff, and even there they can't manage to have a working driver in time. So what remains are Marek and Jerome contributing as time allows...

  9. #29
    Join Date
    May 2011
    Posts
    54

    Default

    Quote Originally Posted by marek View Post
    No, there isn't.


    We have bug reports that some apps are too slow.
    IMHO need some documentation or ticket for TTM heuristics.

  10. #30
    Join Date
    May 2011
    Posts
    54

    Default

    Quote Originally Posted by Beve3rly View Post
    I could write some more about it. Maybe even a full-blow essay. Unfortunately I am not a good writer, so I will let it be in my mind.
    That would be amazing! And it is very difficult to understand the code.

Posting Permissions

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