Announcement

Collapse
No announcement yet.

AMD RadeonSI Gallium3D Begins Simple CL Demos

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

  • #21
    Originally posted by vadimg View Post
    Setting the following environment variables is enough to make it work properly on my card (AMD HD5750), I believe it should be enough for any cards supported by r600g:

    Code:
    MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding force_glsl_extensions_warn=true
    This indeed fixes tropics & sanctuary rendering (on 6670), thanks a lot!

    Comment


    • #22
      I understand that many people play the open source shooters you like to use as benchmarks, but they don't stress modern hardware, therefore they -can't- represent what the hardware can do. It's just not possible with the games that you benchmark to represent performance on modern cards. You really -need- to update the game benchmarks to include modern day games that can stress modern day cards.
      Like Calinou said, Xonotic can already stress cards. It's not difficult at all to make any card slow, just keep adding effects

      Comment


      • #23
        I disagree. Xonotic renders just fine even on my IGP 4200. It is not a very stressful game. Maybe I can make it stressful by rendering it at superspeed or something, but that is not at in indicative of actual gameplay performance. But even then it just doesnt do very much. There are many card features that it just doesnt do. Alot of things that it can't stress because it doesnt implement them. Face the facts The open source games are not stressful. They -CAN'T- represent performance of modern cards..

        EDIT: I'm not saying that the open source games shouldnt be benchmarked... Of course they should, people play those games and they deserve to now how those games perform. But people also play Steam games, and HIB games, and Windows games with wine. Those people also deserve to know how those games perform.

        For example, I play Eve Online in wine, It's awesome. I would love to see benchmarks. I've also recently been playing through HL2 again. I would love to see benchmarks of that. I just don't think it is unreasonable to ask for benchmarks of games that people actually play. Thats kinda the whole point. And no Unigine doesnt count. If you want to benchmark games that use the unigine engine thats fine, but the demos are not games. People don't play the demos.

        I want game benchmarks of real games that real people play.
        Last edited by duby229; 05-25-2013, 11:16 AM.

        Comment


        • #24
          Originally posted by duby229 View Post
          For example, I play Eve Online in wine, It's awesome.
          I play Eve too but that game is not good for benchmarking. Or better, the most Online Games are not a good choice for benchmarks because they change often. Look at Eve This month, the rolled out an Patch for New Capital Textures.
          Last edited by Nille; 05-25-2013, 11:31 AM.

          Comment


          • #25
            Originally posted by Nille View Post
            I play Eve too but that game is not goot Game for benchmarking. Or better, the most Online Games are not and goog choice for benchmarks because the change often. Look at Eve This month, the rolled out an Patch for New Capital Textures.
            That's the best time to benchmark is during feature releases.

            Comment


            • #26
              Originally posted by curaga View Post
              Like Calinou said, Xonotic can already stress cards. It's not difficult at all to make any card slow, just keep adding effects
              A good benchmark is not always a slow benchmark, some very old game engine are likely to be slow if they are used to render scene too complex wrt the target they were designed for.
              Some custom map on UT99 were unplayable whereas still being less complex than UT2K4 one for instance.
              Recent gfx card improvements tend to reduce the number of draw call per frame : instancing does nothing fancy under the hood, it executes the same number of shader ; however the cpu only a couple of draw call instead of hundreds, that's why you can achieve 2 or 3x more fps, depending on the load. The same can be said for geometry shaders : they are slow, but they can be used to avoid multiple passes in some situations (cubemap textures) and represent an overall gain.

              Comment


              • #27
                I really wonder when I could start to use any OpenCL program with my HD6850.
                Because it still doesn't work and have GPU lockup when I try to use any OpenCL program, it they doesn't give segmentation fault before!
                (Using llvm and mesa trunk...)

                Now, 7000 series start to run OpenCL demos before 6000 series? Sad...

                Comment


                • #28
                  Originally posted by Death Knight View Post
                  Now, 7000 series start to run OpenCL demos before 6000 series? Sad...
                  Don't think that is correct. AFAIK the GCN (77xx and up) parts are catching up with the NI and earlier parts, ie the test programs that are starting to work on 7xxx should already be working on your 6850.

                  Comment


                  • #29
                    Originally posted by Michael View Post
                    Most of the time when I try running Unigine on the open drivers usually results with incorrect rendering.
                    The Unigine engine is probably the worst OpenGL engine you'll ever come across. It's not written for OpenGL, it's written for an OpenGL-like API that somehow happens to work with proprietary drivers. You need a series of out-of-spec workarounds to make it work with a strict OpenGL implementation like Mesa (Vadim already mentioned them in this thread). Yes, it's unbelievable how so beautiful Unigine benchmarks can be so bad, but it's true. There have been several attempts to contact Unigine for them to *finally* fix their engine.

                    Note that the proprietary drivers pass about 70% of piglit, which can be interpreted such that they implement only 70% of OpenGL, which covers both strictness (disallowing invalid shader code and commands, which is very important) and correctness (if all shaders and commands are valid). The open source drivers usually pass about 95% of piglit. Obviously, some applications which work with proprietary drivers like the Unigine engine cannot work with Mesa due to its strictness. You can either say in your articles that Unigine is broken or you can pretend Unigine doesn't exist, but saying that it's a problem with Mesa is a lie.

                    Comment


                    • #30
                      Perhaps it will be useful if Michael states in several articles that Unigine needs fixing? Maybe his word has some more clout, making them notice.

                      Comment

                      Working...
                      X