Announcement

Collapse
No announcement yet.

Catalyst 10.1 Still Trash In Heaven, But Good News

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

  • curaga
    replied
    Perhaps they're waiting because in the current state nothing can run the demo w/ full details?

    Leave a comment:


  • tmpdir
    replied
    Originally posted by bridgman View Post
    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.
    So the specs are ready and implemented in heaven, meaning the 'heaven' release is waiting on a catalyst version supporting the final extension specs? Or are they waiting because the spec themself are not frozen yet, with the chance on a code change?

    Good to see opengl at least following directx. Will these extension become part of the official standard?

    Leave a comment:


  • gbeauche
    replied
    Originally posted by Kano View Post
    Who from ATI is responsible for the Unigine Heaven delay? I see no reason why one hardware vendor should force a software vendor not to release any kind of software. It does not matter if the driver still has bugs or not.
    Or it could simply be that Unigine Heaven people found in AMD an excuse to delay. I mean, they could just release the SW if it were ready. How could a HW vendor force a SW vendor to delay? Unless some bits were obtained through NDA, I don't see how... So, just blame the Unigine Heaven people.

    An alternative is they expect their engine to look poor on NVIDIA so they really prefer to wait for AMD to release correct driver first.

    Leave a comment:


  • Qaridarium
    replied
    Originally posted by deanjo View Post
    I'm starting to think that the first card we will the Unigine Heaven benchmark in linux will be a Fermi based one.
    the ironic on this part is not nvidias first no the ironic is amd will be the first but only 1 week ;-) or 1 day...

    1 day before fermi comes out amd push a hotfix beta driver out be sure..

    Leave a comment:


  • Kano
    replied
    @bridgman

    Who from ATI is responsible for the Unigine Heaven delay? I see no reason why one hardware vendor should force a software vendor not to release any kind of software. It does not matter if the driver still has bugs or not.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Joe Sixpack View Post
    I've actually read something similar to this in the past. I've heard certain ATI issues with wine or xorg stemming from Nvidia actually providing more functionality than required by spec. This situation has come up dozens of times. Can you comment on it?
    OpenGL has a long history of vendor extensions getting added, as that was part of the design to allow hardware makers to differentiate their cards. NVidia's are typically used more than others simply because for a long time they were the only real option for high quality 3D graphics on linux. Now that alternative drivers are catching up, it's less likely to be an ongoing problem because new software will take other hardware into account from the beginning. Hopefully, anyway. Also, part of the point of the newer OpenGL 3 versions is to standardize some of the extensions both companies were supporting to help reduce the problem.

    Leave a comment:


  • Joe Sixpack
    replied
    Originally posted by bridgman View Post
    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.
    I've actually read something similar to this in the past. I've heard certain ATI issues with wine or xorg stemming from Nvidia actually providing more functionality than required by spec. This situation has come up dozens of times. Can you comment on it?

    Leave a comment:


  • Sockerdrickan
    replied
    Originally posted by Kazade View Post
    Does putting:



    at the top of the frag shader fix it?
    Actually I already use that line. It does not help at all though.

    Leave a comment:


  • Kazade
    replied
    Originally posted by Sockerdrickan View Post
    out vec4 color; //right there


    And no shadermaker probably does not use a forward compatibility context.
    Does putting:

    precision highp float;
    at the top of the frag shader fix it?

    Leave a comment:


  • Sockerdrickan
    replied
    Originally posted by rohcQaH View Post
    I'm no expert on GLSL, but does your code actually set the color somewhere?
    out vec4 color; //right there


    And no shadermaker probably does not use a forward compatibility context.

    Leave a comment:

Working...
X