Page 4 of 10 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 97

Thread: AMD Catalyst For Linux On The "Blacklist Of Junk"

  1. #31
    Join Date
    Aug 2007
    Posts
    6,615

    Default

    Basically you see some profiles in /etc/ati dir, maybe used for crossfire. crossfire with heaven did not work - it does not work on win as well using opengl. That was the main benchmark i wanted to try with it - really disappointing. Maybe it works with idtech4 games - but those run fast enough with one hd 5670 - heaven does not.

  2. #32

    Default

    I've been meaning to run a new set of CrossFire benchmarks to see what Catalyst does these days.... Maybe next week.

    Years ago, AMD also requested how process names are made within the Phoronix Test Suite (i.e. doom3-benchmark vs. d3-benchmark), so maybe I'll run some benchmarks that generate obscure process names to see if the blob is still doing funny checks.

  3. #33
    Join Date
    Oct 2007
    Posts
    1,269

    Default

    Quote Originally Posted by Michael View Post
    And if you think it's Martin (KWin), your guess is wrong.
    Dave Airlie?

  4. #34
    Join Date
    May 2011
    Posts
    13

    Default Composite Manager

    Anyone that did write a Composite Manager will say the same. Even NVidia driver have bug when run for days in a composite manager (but they are by far the best we have at the moment). Intel it's power management and compositing that don't live well together. But AMD/ATI, it's just another of crappyness. You will get so many bug report from their users, that it's just a good idea to stop bothering and blacklist their driver. Driver are maybe going better for games, but compositor is another story. If you want something stable and fast, you will be better with your own software scenegraph backend.

    And I know exactly who did send this mail. He will surely release some Window/Composite Manager by the end of the year and people have been speaking about this for sometimes now :-)

  5. #35
    Join Date
    Apr 2010
    Posts
    62

    Default

    Soo... let me get this straight: 2 f*king years ago, some unnamed developer said fglrx was bad. And now, Michael posts an "article" claiming the driver is on a "blacklist of junk".

    Very solid piece of journalism Michael, well done...

  6. #36
    Join Date
    May 2011
    Posts
    13

    Default

    dcc24: do you write a Composite Manager ? My guess is no as if you were, you would just agree.

  7. #37
    Join Date
    Aug 2009
    Posts
    87

    Default

    Quote Originally Posted by Vi0L0 View Post
    diff -uN glxinfo wine_glxinfo:

    -OpenGL vendor string: Advanced Micro Devices, Inc.
    +OpenGL vendor string: ATI Technologies Inc.
    also run glxinfo to display limits and diff the 2 outputs ... you'll see why wine on current catalyst does not work with heavy shaders.

    anyway I am using catalyst since forewer and never had many problems. my main gripe is window resizing artifacts in xfce (NO COMPOSITING ENABLED) and the driver installation routine (rm -rf /etc/ati, then reinstall with X stopped and kernel module manualy unloaded).

    I tried some simple OpenGL programming, no issues so far (it was very simple). Some wine problems with some games, but wine is a chapter in itself.

    I am tempted to go Nvidia, but I hate the company with a passion for some of their market politics (mainly CUDA).

  8. #38
    Join Date
    Aug 2012
    Posts
    16

    Default

    Quote Originally Posted by Vi0L0 View Post
    diff -uN glxinfo wine_glxinfo:

    -OpenGL vendor string: Advanced Micro Devices, Inc.
    +OpenGL vendor string: ATI Technologies Inc.
    nothing wrong here. glGetString(GL_VENDOR) return the ati string on mswin so this is a must be for wine.

  9. #39
    Join Date
    Jan 2011
    Posts
    457

    Default

    A argument could be, 'Is anyone helping AMD/ATI' to develop A1 drivers for Linux?

  10. #40
    Join Date
    Feb 2012
    Posts
    43

    Default

    Quote Originally Posted by bridgman View Post
    No. The radeon *hardware* uses proprietary *microcode*, just like most modern CPUs. That microcode happens to be driver-loaded on radeon hardware (and Intel/AMD CPUs) rather than being permanently burned into the chip on other hardware.

    permanently burned is a misconception, most Intel and Phenom CPU's can upgrade the microcode, tho it needs to be done on every boot else it falls back to the bios version.

Posting Permissions

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