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

[phoronix]

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

There's golden register setting updates available for newer GCN hardware on the AMDGPU kernel driver, but it's not immediately clear if these changes will mean any performance or stability improvements for owners of Tonga, Iceland, Polaris, Carrizo, and Stoney hardware...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-Golden-Updates-VI

[boxie]

I would guess minor speed bumps at best, since most of these changes would be tweaks to existing golden settings, no?

[dungeon]

Generaly and primarily means more stability i guess... so perf might even degrade here and there

[Veto]

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.

[MaxToTheMax]

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.

[smitty3268]

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.

[Veto]

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

[MaxToTheMax]

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.)

[Veto]

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

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

[drSeehas]

... Tonga, Iceland, Polaris, Carrizo, and Stoney ...

What about Fiji?
Fiji is Volcanic Islands too.