E-450 graphics performance issues

[brent]

1. Modern toolkits are using more advanced RENDER features. It's not possible to accelerate these and still be RENDER spec compliant on older GPUs because RENDER semantics don't map well to 3D hardware. It is possible accelerate them on modern GPUs, but the complexity starts to rival a 3D driver. It that case it starts to make more sense to take advantage of the 3D driver (better state tracking, integrated shader compiler) with something like glamor.

OpenGL isn't a good fit for 2D operations, though. What happened to the generic Gallium Xorg DDX efforts? Makes far more sense than glamor!

2. EXA was designed years ago and does not provide the necessary infrastructure to accelerate mode advanced RENDER features without an overhaul.
Thus, you end up with SW fallbacks for certain operations which means data ping-ponging between GPU and CPU buffers which almost always ends up being slower than pure CPU rendering or pure GPU rendering. You can try the glamor support in git which should improve things going forward as glamor picks up support for accelerating more and more operations using OpenGL.

Actually, overall, glamor acceleration feels even slower, and there's ugly tearing everywhere. Using glamor might be easy, but I don't think it is the way to go for great 2D acceleration. IIRC Chris Wilson came to the same conclusion.

Intel has already shown that it is possible to accelerate Render well and without (slow) fallbacks.

[brent]

Have you checked modern NVidia hardware ? You mentioned performance on "an older NVidia GPU" which probably had 2D hardware acceleration.

It's not that old. It's a GT200 generation GPU, and as far as I know NVidia dropped the 2D engine earlier, starting with G80. For some time, 2D performance was quite bad with these GPUs and Nvidia's drivers, but they fixed and continued to improve it, and now 2D acceleration is crazy fast.

[agd5f]

OpenGL isn't a good fit for 2D operations, though. What happened to the generic Gallium Xorg DDX efforts? Makes far more sense than glamor!

The gallium xorg state tracker uses EXA which has all of the limitations I've previously mentioned. You can use it today if you enable it in your mesa build.

Actually, overall, glamor acceleration feels even slower, and there's ugly tearing everywhere. Using glamor might be easy, but I don't think it is the way to go for great 2D acceleration. IIRC Chris Wilson came to the same conclusion.

Intel has already shown that it is possible to accelerate Render well and without (slow) fallbacks.

And they spent months developing their own acceleration architecture (sna) to do it. glamor is just another avenue to accomplish the same goal and has the advantage or leveraging all of the effort already put into the 3D drivers. Note also that micro-benchmarks do not always dictate a good user experience. While the current EXA code might not perform great on certain micro-benchmarks, the overall desktop experience is decent because most apps rarely use the specific slow paths and more and more desktop applications use GL directly. With things like wayland and more applications using some variant of GL directly, improving micro-benchmarks for RENDER is not necessarily a good use of resources. It's open source however. If someone wants to write a better RENDER acceleration architecture, everything you need is there.

[brent]

Note also that micro-benchmarks do not always dictate a good user experience. While the current EXA code might not perform great on certain micro-benchmarks, the overall desktop experience is decent because most apps rarely use the specific slow paths and more and more desktop applications use GL directly.

As I said before, it's not just slow in micro-benchmarks (e.g. x11perf), but also in real applications. For instance, scrolling in gnome-terminal or evince is very slow. If 2D performance was acceptable, I would not have complained to start with. Also, it doesn't look like fallbacks are the issue here. It's just that some operations are "accelerated" very slowly.

[agd5f]

As I said before, it's not just slow in micro-benchmarks (e.g. x11perf), but also in real applications. For instance, scrolling in gnome-terminal or evince is very slow. If 2D performance was acceptable, I would not have complained to start with. Also, it doesn't look like fallbacks are the issue here. It's just that some operations are "accelerated" very slowly.

Are you using aliased fonts (which cause a fallback)? For evince, it may depend on what features are used in the pdf. Scrolling here seems fine on ontario chips.

[kobblestown]

What, specifically, do you think should be "quicker" (ie what parts of the chip do you think should be progressing faster in terms of us writing the code, learning the hardware, releasing code and writing documentation) ?

Like, you know, the whole thing. Performance and feature parity with fglrx. I read you comment about the 1000 man-years and the OSS team at AMD being 4 people means that will happen in 250 years. Ok, there are other OSS developers but they need documentation in order to be most effective. So yes, I would like the development of the OSS drivers to be quicker. You choose where you efforts are best spent. I have a 4 year old HD3650. Are you ready to bet that the OSS driver performs with more than half the speed of the proprietary one on average? Or the worst case is better than 1/3 of fglrx performance? And I'm not even mentioning the UVD because for that chip it's not supported by fglrx either. In fact, the whole chip isn't supported in new version of fglrx IIRC, but that's another story. I paid for this stuff and I cannot use it properly!

Gee, I didn't want to turn bitter. As I wrote, I explicitly prefer AMD hardware because of said OSS policy. And I wanted to let AMD know about it as an encouragement. It's just sad that the nouveau guys can do an equally good job without any support from nVidia.

[dungeon]

As I said before, it's not just slow in micro-benchmarks (e.g. x11perf), but also in real applications. For instance, scrolling in gnome-terminal or evince is very slow. If 2D performance was acceptable, I would not have complained to start with. Also, it doesn't look like fallbacks are the issue here. It's just that some operations are "accelerated" very slowly.

I avoid many gtk3 themes as many of these cause slownes in scrolling. But yeah, that (and other interfaces i mention) is clear evidence that something is leaved unaccelerated in radeon. Dont know what is it, but seems to me it is one little feature who buged us so badly .

Actualy i just know it is kms/exa thing , ums/exa don't have all these problems/slowness .

[brent]

Are you using aliased fonts (which cause a fallback)? For evince, it may depend on what features are used in the pdf. Scrolling here seems fine on ontario chips.

No, I am using antialiased fonts. And all PDFs seems slow, even basic text PDFs. Basically, scrolling with the mouse wheel or cursor keys either lags (the "chewing gum" effect) or chokes and runs non-smoothly with very low update rate.

[dungeon]

Did performance of gtk3 apps improve if you use some light themes with default built-in engine, something like this:

http://archlinux.org.ru/forum/viewtopic.php?f=29&t=9148

[bridgman]

Like, you know, the whole thing. Performance and feature parity with fglrx. I read you comment about the 1000 man-years and the OSS team at AMD being 4 people means that will happen in 250 years. Ok, there are other OSS developers but they need documentation in order to be most effective.

So yes, I would like the development of the OSS drivers to be quicker. You choose where you efforts are best spent. I have a 4 year old HD3650. Are you ready to bet that the OSS driver performs with more than half the speed of the proprietary one on average? Or the worst case is better than 1/3 of fglrx performance?

And I'm not even mentioning the UVD because for that chip it's not supported by fglrx either. In fact, the whole chip isn't supported in new version of fglrx IIRC, but that's another story. I paid for this stuff and I cannot use it properly!

Thanks, but I guess I was looking for more specifics than that. You talk about performance, but that is the area *least* dependent on documentation. I understand that you're unhappy and am not trying to make things worse, but there were some unrealistic expectations floating around at the start of the project (all apparently based on the premise that graphics driver development was easy) and I thought we had put them to bed a couple of years ago.

The main problem with performance is that there aren't many developers working on making the driver go faster. There are what seem to be obvious problem areas for investigation (eg Warsow performance is out of line) and generally finding a good fix for the slow cases makes other apps run a bit faster as well. Our guess was that 60-70% performance on average could be reached with the anticipated # of community developers available to work on the driver and the r300 stack seems to have already reached that point. We expected that level of 3D performance combined with better integration with compositors would provide a pretty good user experience for all but gaming on the very lowest end hardware, and I think that is still the case.

One thing I didn't expect is the degree of focus on higher levels of GL support -- our expectation had been that there would be more interest in raising performance than in raising GL level (so yes I expected to see a faster GL 2.1 driver at this point, running at 60-70% of fglrx performance, rather than GL 3-ish driver with 40-50% of fglrx performance).

I didn't say 250 years, and obviously if I thought it would take 250 years I would be doing something that provided more immediate gratification, like planting walnut trees or something. The relationship between "useability" and effort is quite non-linear. My question was why anyone was expecting performance and feature parity quickly and easily in the first place ? The developers certainly aren't saying that; we certainly aren't saying that, and the few people who *were* saying it didn't have enough development background to be credible sources.

When you talk about feature parity what are you actually talking about ? UVD was carved out at the start, power management has been discussed and has been made a priority recently, performance is largely independent of documentation and GL level is continuing to progress pretty quickly (and is already pretty close to the limit of what your hardware will support anyways) -- what else is there ?