Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 46

Thread: Ubuntu Has Another Special ATI Catalyst Driver?

  1. #21
    Join Date
    Apr 2007
    Posts
    99

    Default

    Quote Originally Posted by Qaridarium View Post
    no bashing fglrx is a phoronix valid rule...

    you are simple not an phoronix member if you don't bash fglrx....

    only the amd payed guys can not join this fun.......

    but bridgman if you read between the line very smart you can read a fglrx bash to because he is the opensource man of amd LOL

    so in the end the netiquette of phoronix is bashing fglrx or be kicket!
    I wonder if AMD, internally, jokes about the unfortunate facts of fglrx too.

  2. #22
    Join Date
    Oct 2008
    Posts
    3,101

    Default

    Quote Originally Posted by damentz View Post
    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.

  3. #23
    Join Date
    Oct 2007
    Posts
    912

    Default

    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.

  4. #24
    Join Date
    Oct 2008
    Posts
    3,101

    Default

    Quote Originally Posted by mirv View Post
    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.

  5. #25
    Join Date
    Oct 2007
    Posts
    912

    Default

    Quote Originally Posted by smitty3268 View Post
    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.

  6. #26
    Join Date
    Oct 2008
    Posts
    3,101

    Default

    Quote Originally Posted by mirv View Post
    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.

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

    Default

    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.

  8. #28
    Join Date
    Feb 2010
    Posts
    1

    Arrow

    Quote Originally Posted by raulromania View Post
    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.

  9. #29
    Join Date
    Oct 2008
    Posts
    3,101

    Default

    Quote Originally Posted by bridgman View Post
    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.

  10. #30
    Join Date
    Dec 2007
    Location
    Merida
    Posts
    1,099

    Default

    Quote Originally Posted by smitty3268 View Post
    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.

Tags for this Thread

Posting Permissions

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