If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I wonder if AMD, internally, jokes about the unfortunate facts of fglrx too.

I'm sure they do, these are smart guys and they know the quality of the product they're putting out.

Honestly, if AMD just put out a roadmap stating when they thought all the various problems with fglrx might be solved, that would be a good start. Right now it's like Flash - there are so many problems and no indication about whether AMD even intends to fix them, let alone whether it's under progress now or scheduled for 5 years later.

I'm quite sure the drivers don't have as many problems as people keep suggesting. I'll note that many will say "it's got so many problems, blah blah blah", but few actually state any problems, and of those that do, it's rarely a problem but rather a missing feature.
So I imagine AMD says dilligaf a lot.

I'm quite sure the drivers don't have as many problems as people keep suggesting. I'll note that many will say "it's got so many problems, blah blah blah", but few actually state any problems, and of those that do, it's rarely a problem but rather a missing feature.
So I imagine AMD says dilligaf a lot.

You're right in that a lot of it is missing features rather than outright bugs.

What does fglrx need for people to take it seriously?

Video accelerated decoding needs to work, out of the box, with no fiddling and no errors. And no breaking when a new driver comes out each month.

xserver no-backfill. Need i say more?

Supporting new versions of x and the kernel in less than 6 months. Heck, nvidia is supporting this stuff before they're even released.

constant crashes when watching video. ok, this one might already be fixed, i haven't actually used fglrx in a while because the oss drivers are working better for me.

This is analogous to the Flash situation, to me. Flash mostly works, it's just that it does so rather poorly and there's no indication that things are going to get better any time soon.

You're right in that a lot of it is missing features rather than outright bugs.

What does fglrx need for people to take it seriously?

Video accelerated decoding needs to work, out of the box, with no fiddling and no errors. And no breaking when a new driver comes out each month.

xserver no-backfill. Need i say more?

Supporting new versions of x and the kernel in less than 6 months. Heck, nvidia is supporting this stuff before they're even released.

constant crashes when watching video. ok, this one might already be fixed, i haven't actually used fglrx in a while because the oss drivers are working better for me.

This is analogous to the Flash situation, to me. Flash mostly works, it's just that it does so rather poorly and there's no indication that things are going to get better any time soon.

Well for people to take it seriously, the 3D stuff needs to work. And it does. The "people" here most important are the workstation market - it has been said many times that this area is the target of fglrx.

Video accelerated decoding would be nice - but do bear in mind that AMD have never officially released it, and don't support it. So it's strictly something missing at the moment, albeit something that a good many would like.

xserver-backfill - yep, you'll need to say more (at least for me to understand). I can't remember too much about that as it was something that never affected me.

Not had a problem with video in a long time here. Used to have issues with xv (crashes typically), but it's worked fine for well over a year now (for me at any rate). Of course, I don't use much eye candy for my desktop (e16 user, occasionally e17) so I may well not encounter some of the problems that others have.

Well for people to take it seriously, the 3D stuff needs to work. And it does. The "people" here most important are the workstation market - it has been said many times that this area is the target of fglrx.

Video accelerated decoding would be nice - but do bear in mind that AMD have never officially released it, and don't support it. So it's strictly something missing at the moment, albeit something that a good many would like.

xserver-backfill - yep, you'll need to say more (at least for me to understand). I can't remember too much about that as it was something that never affected me.

Not had a problem with video in a long time here. Used to have issues with xv (crashes typically), but it's worked fine for well over a year now (for me at any rate). Of course, I don't use much eye candy for my desktop (e16 user, occasionally e17) so I may well not encounter some of the problems that others have.

Yes, i know fglrx is targeted towards the workstations. That's my point, is that it sucks for the desktop linux usage i want to use it for. I'm sure that for their paying customers it's better, but I'm selfish and really don't care about them.

The xserver backfill thing was in response to terrible desktop performance the driver had when maximizing windows and doing other wm tasks. I'm not sure AMD ever even officially acknowledged the problem, but bridgman told users to apply the no-backfill patch to the xserver to fix it. Last i heard, it was still an issue for fglrx, and the xserver folks weren't going to accept it upstream because they viewed it as a hack to work around a fglrx-only bug that would end up affecting all the other drivers which already worked correctly. Never heard any more from amd besides applying that patch, and that they were "looking into it". That was probably a year ago now.

I'm not sure if I ever "officially acknowledged the problem" either (I'm not the official problem-acknowledger ) but we sure talked about it for a long time. Here's the background one more time :

1. The "no backfill" code had been shipping in most distributions for years in order to improve performance on all hardware - I think it was first added to Fedora then spread across to other distros as well. Looking back, we now know that all hardware needed the patch because all hardware ran with XAA acceleration at the time, and XAA did not accelerate the "backfill" (copying big chunks of data from video memory to system memory) which was required under certain conditions.

2. Somewhere in late 2008 / early 2009 a problem appeared using Intel hardware, resulting in (IIRC) previously used screen buffers re-appearing on the screen, which could contain sensitive data. Disabling the "no-backfill" code was found to eliminate this problem, so the "no backfill patch" was flagged as a security problem and removed from the next round of distro releases. This resulted in the delays you know about when running a compositor and unminimizing windows etc... on some hardware (mostly ours).

3. Much debate and finger-pointing ensued. In the end, it turned out that removing the long-standing "no-backfill" patch caused performance problems when running with XAA acceleration and compositing but not with EXA or other similar acceleration schemes. Note that since IGP parts use a common pool for system and video memory the copy can sometimes be "free" on that hardware but not on discrete GPUs.

4. The root cause seemed to be a discrepancy in the specs for X and related extensions, in the sense that a literal interpretation of the spec resulted in what many called non-intuitive behaviour, ie a large copy of data down to system memory, which was then promptly over-written and discarded. There seemed to be agreement on the problem, but it wasn't clear how to fix the problem other than making that largely redundant copy run faster, which apparently had come for free as drivers moved from XAA to other acceleration APIs.

4. As a short-term fix, Felix implemented a "no-backclear" patch (no-back*clear* rather than no-back*fill*) which returned performance to where it was when distros were all shipping no-backfill, but without the side-effects on Intel (and apparently other) hardware.

5. As a medium-term fix, the 2D acceleration API on fglrx is going to be changed to one which can accelerate the backfill operation, so we'll still be doing the redundant copy (just like all the other hardware vendors) but at least will be doing it quickly. This isn't a real solution, but it works for now and at least everyone will be dealing with the problem in the same way.

6. The real solution, if it ever happens, will involve some TBD changes to the X and extension specs to eliminate the largely wasted copy (maybe something similar to Felix's no-backclear patch), or maybe just to live with it and flag the backfill copy operation as a core function which needs to be accelerated (or at least fast) on all drivers.

It is not the problem to the configure xorg.conf manually. The package scripts for karmic are broken for 10.1. So I gave up. Its not my cup of tea to give up so fast, but i dont want to waste so much time with configuring my system. You are using arch, right? Probably i will try it these days.

Have a look at this thread. Takes no more than a minute, fglrx builds fine and works like a ch... ah... nevermind . Hope this will help you.

4. As a short-term fix, Felix implemented a "no-backclear" patch (no-back*clear* rather than no-back*fill*) which returned performance to where it was when distros were all shipping no-backfill, but without the side-effects on Intel (and apparently other) hardware.

5. As a medium-term fix, the 2D acceleration API on fglrx is going to be changed to one which can accelerate the backfill operation, so we'll still be doing the redundant copy (just like all the other hardware vendors) but at least will be doing it quickly. This isn't a real solution, but it works for now and at least everyone will be dealing with the problem in the same way.

6. The real solution, if it ever happens, will involve some TBD changes to the X and extension specs to eliminate the largely wasted copy (maybe something similar to Felix's no-backclear patch), or maybe just to live with it and flag the backfill copy operation as a core function which needs to be accelerated (or at least fast) on all drivers.

Is anyone actually working on that medium term fix, or is it on the roadmap to eventually be done in a few years? I ask because it's already been 1 year, and it doesn't seem like it would take that long to accelerate a single operation. Unless you mean you are switching the whole driver to use EXA? That could take a year. Otherwise, it seems like you are prioritizing this bug very, very low, and I don't think that you can seriously argue that fglrx is ready for "normal" desktop use if that's the case. Maybe AMD isn't even saying that, and they're saying that if you can get lucky and get it working then great, but don't expect any more than that.

Is anyone actually working on that medium term fix, or is it on the roadmap to eventually be done in a few years? I ask because it's already been 1 year, and it doesn't seem like it would take that long to accelerate a single operation. Unless you mean you are switching the whole driver to use EXA? That could take a year. Otherwise, it seems like you are prioritizing this bug very, very low, and I don't think that you can seriously argue that fglrx is ready for "normal" desktop use if that's the case. Maybe AMD isn't even saying that, and they're saying that if you can get lucky and get it working then great, but don't expect any more than that.

It's being worked on. That I think is the most I can write without getting into trouble.