Announcement

Collapse
No announcement yet.

Radeon Gallium3D R600g Color Tiling Performance

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

  • #16
    Originally posted by tmikov View Post
    Fair enough. But what would be a good synthetic stress test?

    Also, do you have an idea why the blob is faster? Could it be memory clocks, power management, etc?
    This mesa demo fill probably have double perf with 2d tiling on (depending on the GPU has the high end GPU benefit more from 2D tiling)
    http://cgit.freedesktop.org/mesa/dem...rc/perf/fill.c

    There is not a single thing that explain the gap btw open source driver and closed source driver. There is no secret way to do thing, we have tools to capture fglrx command stream and there is nothing fundamentally different. Proper power management support with use of on chip governor to manage clock will probably improve performance a bit, better buffer heuristic placement, better shader compiler, less cpu overhead, less cp stalling, ... many little things like those add up.

    Comment


    • #17
      @tmikov

      Tried to profile it yet? Oprofile will show the cpu use, radeontop gpu use, latencytop any waits.

      Comment


      • #18
        Originally posted by pingufunkybeat View Post
        Like I said, this is for driver developers to answer, I lack the knowledge. Marek and Alex have already written that all hardware functionality is used (only HiZ is not on by default). If I remember correctly, Jerome Glisse did profile the driver and couldn't find one single bottleneck, but many small ones. I can't find a link at the moment, perhaps somebody is better at googling.


        Only if they operate completely asynchronously. If the GPU ever has to wait for the driver before continuing, then no.

        Even if your processor is mostly idle, a simple cache miss might cause a considerable delay while your GPU is waiting for the next instruction.

        But again, I'm not a GPU developer. I just don't believe that using less than 100% of CPU all the time means that there are no bottlenecks in the driver. A 1ms delay is a 1ms delay, even if it only happens occasionally.
        Neither am I a GPU developer of course. At best, I've tried programming with OpenGL, so even there I know just a few basics. But I still don't think it's s few small things here and there. And someone may know better whether compression can play any part in the specific benchmark of course, cause if it can, we likely found the culprit on the "single texture test" and maybe radeon is doing fine, who knows.

        Comment


        • #19
          This makes me wonder... It's just a wild guess, but are you making sure that the GPU is trying to render only your texture, and nothing else? If the test was running like glxgears, then the difference in performance could very well be due to the GPU having to render all the windows in the background and such as well as the test object. And even if it is running fullscreen, are there any guarantees that the GPU is not trying to render something in the background or offscreen, before drawing the test texture on top?

          Comment


          • #20
            Originally posted by GreatEmerald View Post
            This makes me wonder... It's just a wild guess, but are you making sure that the GPU is trying to render only your texture, and nothing else? If the test was running like glxgears, then the difference in performance could very well be due to the GPU having to render all the windows in the background and such as well as the test object. And even if it is running fullscreen, are there any guarantees that the GPU is not trying to render something in the background or offscreen, before drawing the test texture on top?
            Try "sudo init 3" and using GLES

            Comment

            Working...
            X