Announcement

Collapse
No announcement yet.

With R600g Now Supporting OpenGL 4.1, See How The Open-Source Performance Compares To AMD Catalyst

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

  • Marc Driftmeyer
    replied
    Who cares about nearly 6 year old hardware?

    Leave a comment:


  • Azrael5
    replied
    Excellent improvement

    Leave a comment:


  • bridgman
    replied
    Originally posted by airlied View Post
    Apple does something tricky with fp64 but I'm not 100% sure what.
    https://developer.apple.com/opengl/capabilities/
    • ARB_gpu_shader_fp64 functionality is implied by OpenGL 4.0, but not exported on renderers marked by "~"
    • ARB_vertex_attrib_64bit functionality is implied by OpenGL 4.1, but not exported on renderers marked by "~"
    At first glance that seems remarkably similar to Dilbert nodding his head periodically and the salesman timing his lies to align with the nods

    Seriously though, at least it's a precedent that game developers might have already seen.

    Whether the shaders fail to compile or they produce garbage, either way actually *using* the extension is not going to end well, but I suppose one could argue that an untrue implication is less bad than a lie. I have trouble with them personally because I see more damage done by untrue implications than by lies (untrue implications appear to be the foundation of our modern political system) but if it turns out to be a generally accepted way of communicating the situation it might be worth following for now. Good catch !

    Leave a comment:


  • dungeon
    replied
    Originally posted by bridgman View Post
    Are you guys thinking about something like a build option to force-fake fp64 on hardware that doesn't have native support ? If you're actually asking the developers to lie about support then obviously you haven't been following the latest Dilbert story arc:

    http://dilbert.com/strip/2015-12-14 (then follow it forward)
    Lies are on OSX as Dave show, lies are with Catalyst too, whatever you do so that your user suffer less is good... thing is do you lie for the good or for the bad, even truth is not useful if it is for the bad
    Last edited by dungeon; 17 December 2015, 04:56 PM.

    Leave a comment:


  • airlied
    replied
    Apple does something tricky with fp64 but I'm not 100% sure what.
    https://developer.apple.com/opengl/capabilities/
    • ARB_gpu_shader_fp64 functionality is implied by OpenGL 4.0, but not exported on renderers marked by "~"
    • ARB_vertex_attrib_64bit functionality is implied by OpenGL 4.1, but not exported on renderers marked by "~"

    So it seems they might advertise GL 4.1 but not advertise the extensions as a sign that they don't actually support it.

    I've no idea what happens if you run fp64 code on this driver, whether it fails to compile the shaders or just produces garbage.

    Dave.

    Leave a comment:


  • bridgman
    replied
    Are you guys thinking about something like a build option to force-fake fp64 on hardware that doesn't have native support ? If you're actually asking the developers to lie about support then obviously you haven't been following the latest Dilbert story arc:

    http://dilbert.com/strip/2015-12-14 (then follow it forward)

    I think the main issue here is that the developers would rather see time going into a proper solution (emulating fp64) than a throw-away solution (announcing fp64 even if you can't support it). The over-ride mechanism is a good solution for temporary gaps, and AFAICS that's what this is.

    EDIT - there seems to be something funny with the bar graphs - the only options seem to be no bars, 2 bars, all-but-2 bars... and I guess maybe all-bars ?
    Last edited by bridgman; 17 December 2015, 03:57 PM.

    Leave a comment:


  • dungeon
    replied
    But opensource drivers does not even have s3tc and/nor texture-float by default

    For both those situation users need to do something about it, if they compile it or maintainer can turn on that or do something about it, package maintainer can also patch mesa and to fake advertise fp64 for all r600 if his users are so lazy

    Leave a comment:


  • xpris
    replied
    Originally posted by agd5f View Post

    As had been noted on just about every r600g thread, someone needs to implement support for fp64 in shaders on asics without native fp64 support.
    Ahh, thanks for explain.

    Leave a comment:


  • agd5f
    replied
    Originally posted by eydee View Post

    Or -- as had been noted in just about every R600g thread -- it should simply return fake data/null like Intel and Nvidia cards do (some of them). While the chance of people wanting to run Metro 2033 on these cards is pretty high, people wanting to calculate Julia/Mandel/etc on these GPUs using GL shaders for fun is pretty rare. At this moment this is the only known usage scenario of fp64. Point is, you can't expect Average Joe to run Steam games with Mesa environment variables. Linux is no longer for the super tech-savvy geeks only.
    Why is that any better than just announcing what is actually supported? It will be broken for any apps that need the fp64. Linux is used by more than just gamers. What about convincing the game developers to only request the extensions they need?

    Leave a comment:


  • jf33
    replied
    Originally posted by eydee View Post
    Or -- as had been noted in just about every R600g thread -- it should simply return fake data/null like Intel and Nvidia cards do (some of them).
    No. Not providing what you advertise is a VERY bad idea. No driver should act like this by default. Such hacks can be useful for some situations, but not in general. This is why overriding the advertised GL version is optional, so that the user can decide by himself. It's not even difficult. So don't change anything about it - it's perfect. And the OpenGL specification is holy.

    Leave a comment:

Working...
X