Announcement

Collapse
No announcement yet.

AMDGPU Golden Setting Updates For Tonga / Iceland / Polaris / Carrizo / Stoney

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

  • smitty3268
    replied
    Originally posted by drSeehas View Post
    Polaris and Stoney are older than Fiji?
    Well, no - those are too new, and AMD is still figuring out the golden settings for that hardware. Fiji is a little more settled.

    Leave a comment:


  • drSeehas
    replied
    Originally posted by smitty3268 View Post
    It probably already had the current golden settings, since they were bringing up the driver on the newer hardware and are now going backwards to update the older ones.
    Polaris and Stoney are older than Fiji?

    Leave a comment:


  • smitty3268
    replied
    Originally posted by drSeehas View Post
    What about Fiji?
    Fiji is Volcanic Islands too.
    It probably already had the current golden settings, since they were bringing up the driver on the newer hardware and are now going backwards to update the older ones.

    Leave a comment:


  • drSeehas
    replied
    ... Tonga, Iceland, Polaris, Carrizo, and Stoney ...
    What about Fiji?
    Fiji is Volcanic Islands too.

    Leave a comment:


  • Veto
    replied
    Originally posted by MaxToTheMax View Post
    Nah, rasterization is always fixed-function. If you don't believe me, the RealWorldTech guy says so right in the video. The GPU may lean on the driver a little bit to help it implement the technique though.
    There are some really interesting comments to the RWT article from a Rob Clark (of freedreno fame?) and a Philip Taylor
    Code:
    Yep, as far as I can tell (based on some research and a lot of wild speculation) it's essentially changing from the traditional IMR rasterisation process of:
    
    for each draw:
      for each primitive:
        for each tile:
          fetch framebuffer tile
          for each pixel:
            execute pixel shader
            update framebuffer tile
          store framebuffer tile
    
    to something more like:
    
    for each draw:
      for each batch of primitives:
        for each tile:
          fetch framebuffer tile
          for each primitive:
            for each pixel:
              execute pixel shader
              update framebuffer tile
          store framebuffer tile
    
    which benefits by improving the spatial locality of framebuffer updates (so they can be cached closer to the shader cores), and looks like it wouldn't have a major impact outside the rasteriser.
    BTW sorry for hi-jacking this comment thread. Hopefully we will get some Phoronix coverage

    Leave a comment:


  • MaxToTheMax
    replied
    Originally posted by Veto View Post
    I doubt it. It is most likely about how the shader is compiled and the order of how it is scheduled on the hardware, which I think is driver responsibility. Though the hardware may of course include special support for accelerating this way of scheduling.
    However I am no expert, and the driver is a closed secret anyway. That is why it would be interesting to hear from some of the Mesa/Nouveau/Gallium developers with better insight
    Nah, rasterization is always fixed-function. If you don't believe me, the RealWorldTech guy says so right in the video. The GPU may lean on the driver a little bit to help it implement the technique though.

    You could emulate this tiled rendering technique in software, by re-running the same draw calls over and over again with successive glScissor calls for each "tile," and in theory maybe that would reduce evictions in the vertex and texture caches. Depending on how smart the caches are designed, it might even prevent each framebuffer snippet from being written to memory until it's completely done. And maybe you could implement an equivalent technique in the driver too. But that would be a whole lot slower than just rendering "naturally" the way the GPU was designed to render, because of the geometry overhead, not to mention software/driver overhead. I think these NVIDIA GPUs have dedicated silicon for tagging each tile with the triangles that intersect it, which is the really hard part (computationally, anyway.)

    Leave a comment:


  • Veto
    replied
    Originally posted by MaxToTheMax View Post
    I think the tiled rasterization is just implemented in hardware and not in the drivers? That's why NVIDIA's design is such an achievement, and why they kept it a secret for so long-- they made tiled rendering completely transparent to software, which was a big deal. I don't think it's possible to implement this technique from the driver, you have to modify the silicon.
    I doubt it. It is most likely about how the shader is compiled and the order of how it is scheduled on the hardware, which I think is driver responsibility. Though the hardware may of course include special support for accelerating this way of scheduling.
    However I am no expert, and the driver is a closed secret anyway. That is why it would be interesting to hear from some of the Mesa/Nouveau/Gallium developers with better insight

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Veto View Post
    It would be very interesting to hear some comments from Mesa / Open source developers on the merits of this and whether the open source drivers should follow suit - or whether it is actually standards non-compliant in some subtle way.
    Yeah, like max mentioned this is a hardware feature. The ARM gpus in Mesa are already using tile rendering.

    I haven't watched that video yet. Tile-rasterization tends to be slower at certain types of workloads, so maybe NVidia came up with some magic in the driver to hide that, or their hardware solution is a bit different from full tile-based rasterization like mobile chips use.

    Leave a comment:


  • MaxToTheMax
    replied
    Originally posted by Veto View Post
    Yes, it would be interesting to here some comments on these register tweaks...

    However, there is something that would be orders of magnitude more interesting to hear comments on. Over on realworldtech.com they have some pretty interesting "breaking news" about the newer nVidia GPUs having changed to use tile based rendering to achieve significant memory BW savings and their performance advantages. It would be very interesting to hear some comments from Mesa / Open source developers on the merits of this and whether the open source drivers should follow suit - or whether it is actually standards non-compliant in some subtle way.

    The article is here: http://www.realworldtech.com/tile-ba...n-nvidia-gpus/
    I highly recommend spending the ~20 minutes on watching the video.
    @Michael: I personally think that would be worthy of a Phoronix article to refer to this video and capture the follow-up forum thread.
    I think the tiled rasterization is just implemented in hardware and not in the drivers? That's why NVIDIA's design is such an achievement, and why they kept it a secret for so long-- they made tiled rendering completely transparent to software, which was a big deal. I don't think it's possible to implement this technique from the driver, you have to modify the silicon.

    Leave a comment:


  • Veto
    replied
    Yes, it would be interesting to here some comments on these register tweaks...

    However, there is something that would be orders of magnitude more interesting to hear comments on. Over on realworldtech.com they have some pretty interesting "breaking news" about the newer nVidia GPUs having changed to use tile based rendering to achieve significant memory BW savings and their performance advantages. It would be very interesting to hear some comments from Mesa / Open source developers on the merits of this and whether the open source drivers should follow suit - or whether it is actually standards non-compliant in some subtle way.

    The article is here: http://www.realworldtech.com/tile-ba...n-nvidia-gpus/
    I highly recommend spending the ~20 minutes on watching the video.
    @Michael: I personally think that would be worthy of a Phoronix article to refer to this video and capture the follow-up forum thread.

    Leave a comment:

Working...
X