Announcement

Collapse
No announcement yet.

Catalyst 10.1 Still Trash In Heaven, But Good News

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Sockerdrickan
    replied
    Originally posted by rohcQaH View Post
    I'm no expert on GLSL, but does your code actually set the color somewhere? Using ShaderMaker, I just tried setting this as "Fragment Shader" and got the expected results. HD5770, catalyst 10.1.
    Code:
    void main()
    {
    	gl_FragColor = vec4(1.0)*0.99;
    }
    not sure if it qualifies as an "OGL 3.2 context" as I didn't dissect shadermaker's sources.
    That is what my vec4 color; was for obviously, and no shadermaker probably don't use a forward compatibility context

    Leave a comment:


  • rohcQaH
    replied
    Originally posted by Sockerdrickan View Post
    The following code will produce black fragments:
    I'm no expert on GLSL, but does your code actually set the color somewhere? Using ShaderMaker, I just tried setting this as "Fragment Shader" and got the expected results. HD5770, catalyst 10.1.
    Code:
    void main()
    {
    	gl_FragColor = vec4(1.0)*0.99;
    }
    not sure if it qualifies as an "OGL 3.2 context" as I didn't dissect shadermaker's sources.

    Leave a comment:


  • deanjo
    replied
    I'm starting to think that the first card we will the Unigine Heaven benchmark in linux will be a Fermi based one.

    Leave a comment:


  • gbeauche
    replied
    Originally posted by Sockerdrickan View Post
    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;
    }
    One to two years ago, there used to be a bug that parsed floating-points using the locale's decimal point instead of plain '.'. This is normally fixed nowadays.

    Leave a comment:


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

    Leave a comment:


  • Sockerdrickan
    replied
    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;
    }

    Leave a comment:


  • bridgman
    replied
    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 ?

    Leave a comment:


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

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • rohcQaH
    replied
    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? )

    Leave a comment:

Working...
X