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

Printable View

Show 40 post(s) from this thread on one page

11-27-2012, 03:50 PM
crazycheese

Quote:

Originally Posted by bobwya

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.
11-27-2012, 07:24 PM
marek

Quote:

Originally Posted by ilyes

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).
11-28-2012, 01:48 AM
ilyes

Hi,

Quote:

Originally Posted by bridgman

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

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

- 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
11-28-2012, 01:55 AM
ilyes

Hi Marek,

Quote:

Originally Posted by marek

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
11-28-2012, 01:55 AM
stalkerg

Quote:

Originally Posted by marek

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?
11-28-2012, 07:55 AM
marek

Quote:

Originally Posted by ilyes

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

We have bug in bugzilla or thread in maillist?

We have bug reports that some apps are too slow.
11-28-2012, 08:19 AM
bridgman

Quote:

Originally Posted by ilyes

Would love to see all these featured in the kernel/mesa!

It's a community developed driver, more contributors would be welcomed.
11-28-2012, 08:28 AM
log0

Quote:

Originally Posted by stalkerg

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...
11-28-2012, 08:33 AM
stalkerg

Quote:

Originally Posted by marek

No, there isn't.

We have bug reports that some apps are too slow.

IMHO need some documentation or ticket for TTM heuristics.
11-29-2012, 02:09 AM
stalkerg

Quote:

Originally Posted by Beve3rly

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.http://www.rxor.info/01.jpg http://www.rxor.info/22.jpg http://www.rxor.info/8.jpg http://www.rxor.info/03.jpg http://www.rxor.info/23.jpg http://www.sbqg.info/21.jpg http://www.ryzu.info/9.jpg

That would be amazing! And it is very difficult to understand the code.

Show 40 post(s) from this thread on one page