Page 1 of 5 123 ... LastLast
Results 1 to 10 of 43

Thread: Catalyst 10.1 Still Trash In Heaven, But Good News

  1. #1
    Join Date
    Jan 2007
    Posts
    15,636

    Default Catalyst 10.1 Still Trash In Heaven, But Good News

    Phoronix: Catalyst 10.1 Still Trash In Heaven, But Good News

    We have just received official word from Unigine that they still are not ready to release their OpenGL Linux version of their Unigine Heaven benchmark. "Unfortunately we were asked by a hardware vendor not to release current version :(," said Denis Shergin, the Unigine Corp CEO...

    http://www.phoronix.com/vr.php?view=Nzk2MA

  2. #2
    Join Date
    Oct 2009
    Posts
    101

    Default

    I would really appreciate it if AMD would do one of the following:
    1. Get their act together with fglrx
    2. Abandon fglrx and throw their full weight behind xf86-video-radeon

    While I appreciate AMD's support for free drivers, the fact of the matter is that the free drivers do not support things like OpenGL 3. It's annoying that I have to choose between a free driver that doesn't support the technologies I want and a non-free driver that *poorly* supports the technologies I want. Oh, and decent 2D acceleration in fglrx would be nice.

  3. #3
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    I would really appreciate it if AMD would do one of the following:
    1) Either get OpenGL 3.x support with their next release, or;
    2) Shut up and just tell the Unigene folks to not wait for them to come with a driver that does OpenGL 3.x instead.

    BTW Fglrx should be called Fgl IMO, because it's geared for workstations and AMD just so happens to allow it to work on Radeon cards.

    The FLOSS drivers (be greatful they release docs and lend paid-for programmers) are geared for regular consumer computers with Radeon cards.

    "ATI sucks! Put some weight behind the linux drivers"
    *ATI does this*
    "AMD sucks because the driver doesn't work (yet)! Please release the specs so we can make our own"
    *AMD does this*
    Some random dude: "I would realy appreciate it if..."
    ME: "Stop whining"

  4. #4
    Join Date
    May 2009
    Posts
    80

    Default

    OGL 2.1 is more than enough. All I need is a decent performance for Team Fortress 2 through wine and free drivers are getting close.

  5. #5
    Join Date
    Nov 2008
    Posts
    784

    Default

    2. Abandon fglrx and throw their full weight behind xf86-video-radeon
    As far as you're concerned, they do. fglrx is mostly maintained for the workstation customers (and has to be maintained for them), but AMD isn't throwing lots of man-power at it to quickly implement consumer-features like video acceleration or shiny, but useless heaven demos.

    Instead, they're developing the OS drivers. They already work very well in a lot of use cases, as far as we can see features are prioritized by end-user needs and the drivers are constantly improving.

    If you're saying that the OS drivers don't mature fast enough then that's probably a valid criticism, but it's debatable if development could be sped up by just transfering all fglrx developers to a codebase they don't even know. (besides, if you hate fglrx so much, would you really want those developers to work on the OS drivers? )

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,571

    Default

    Quote Originally Posted by V!NCENT View Post
    I would really appreciate it if AMD would do one of the following:
    1) Either get OpenGL 3.x support with their next release, or;
    2) Shut up and just tell the Unigene folks to not wait for them to come with a driver that does OpenGL 3.x instead.
    I don't think this is an OpenGL 3.x issue, it's about retrofitting the newest tesselation hardware support (which is *not* part of any OpenGL spec today) into an existing OpenGL 3.2 driver via extensions.

  7. #7
    Join Date
    Jan 2010
    Location
    Stockholm, Sweden
    Posts
    5

    Default

    AMD's GLSL compiler is really bad. It doesn't support floating point temporaries... I thought GPUs were for floating point operations.

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,571

    Default

    Are you talking about the fglrx compiler or the open source one ?

    I'm pretty darned sure that the fglrx compiler *does* support floating point variables (I think the open source one does as well but not 100% sure off the top of my head) - if you're talking about fglrx is there a specific issue or scenario you are talking about ?

  9. #9
    Join Date
    Jan 2010
    Location
    Stockholm, Sweden
    Posts
    5

    Default

    Quote Originally Posted by bridgman View Post
    Are you talking about the fglrx compiler or the open source one ?

    I'm pretty darned sure that the fglrx compiler *does* support floating point variables (I think the open source one does as well but not 100% sure off the top of my head) - if you're talking about fglrx is there a specific issue or scenario you are talking about ?
    The proprietary driver does not support floating point. At least not in an OpenGL 3.2 context. The following code will produce black fragments:

    Code:
    out vec4 color;
    
    void main() {
       color=vec4(1.0)*0.99;
    }

  10. #10
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    All shaders ops are floating point unless you specifically request integers. Older hardware didn't even support integer ops.

Posting Permissions

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