Announcement

Collapse
No announcement yet.

Early Tests Of AMDGPU's DRM-Next Performance For Linux 4.12

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

  • Shevchen
    replied
    Again, thank you very much! (Esp. the Star Citizen part was very interesting, as this is my wonder-game I'm waiting for)

    So, in essence 10 years of driver magic now have to be coded by the engine programmer(s). Thats a pain, but I like it, because you can now shape the code directly to your needs. And now I also know, why so many wrappers fail to bring in a performance improvement. Good stuff.

    Leave a comment:


  • FishPls
    replied
    Originally posted by Shevchen View Post

    Aye, watched it now... still hard to understand WHY DX9 is still faster (I know the draw calls don't saturate the bottleneck, but I still wonder, why the renderer itself is still faster than Vulkan)
    In the Q/A session Dan said that is basically caused by "driver magic". Drivers have been really optimized at handling DX9, and might do some really good tricks to get maximum perf out of it. He talks about it here: https://youtu.be/EX1RKhlOYmY?t=1h38m45s

    Leave a comment:


  • Marc Driftmeyer
    replied
    Originally posted by smitty3268 View Post

    They have a Q&A about that at 1:39. It's not really clear, but it sounds to me as if DX9 is just simpler and things can sometimes be done faster in that situation. Also, the game was originally built for DX9 and there may still be certain pieces targeted directly around that API.

    I also found this quote from a Star Citizen developer interesting about their Vulkan porting efforts:
    It's akin to the notion of Garbage Collection being a false panacea to Retain/Release and later ARC in OS X. If you truly know what you're doing, and Vulkan/Metal demand you do, then Retain/Release will be faster than any other option. If you don't stick with Lattner's compromise ARC. Apple finally dropped Garbage Collection entirely. Whether with Swift of especially Obj-C it is a stupid idea.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Shevchen View Post

    Aye, watched it now... still hard to understand WHY DX9 is still faster (I know the draw calls don't saturate the bottleneck, but I still wonder, why the renderer itself is still faster than Vulkan)
    They have a Q&A about that at 1:39. It's not really clear, but it sounds to me as if DX9 is just simpler and things can sometimes be done faster in that situation. Also, the game was originally built for DX9 and there may still be certain pieces targeted directly around that API.

    I also found this quote from a Star Citizen developer interesting about their Vulkan porting efforts:

    Originally posted by starcitizendev
    What happens, though, if you naïvely port from a higher-level API to a lower level one, as in the case of D3D11 to D3D12 or Vulkan, is that you strip away a layer of driver complexity, and then writing almost the same stuff yourself in the wrapper layer because the code outside the wrapper assumed the conveniences and limitations of what was there before.
    That might seem kind of abstract, so I'll give a concrete example. Under D3D11, when you want a texture loaded on the GPU, you just hand the driver some memory and it gives you back a handle. If you load more than will fit into GPU memory, the driver quietly works out what's best to swap out into normal memory and you don't even know it happened, besides the performance cost. With the new APIs, you're responsible for reserving the right sizes of memory, resizing and swapping where appropriate, etc. Theoretically that's far more efficient, you know what you want where and less stuff gets moved around, but if your outside-wrapper code is still trying to add and remove things without warning, your wrapper just ends up having to handle every possible case anyway, only now you don't have the advantage of a decade of fine tuning by your hardware vendor, so a lot of early Mantle/D3D12 ports actually turned out to run slower rather than faster.
    So a lot of the work in this conversion is about restructuring how the engine approaches render work. As one example, standardising how jobs ask for temporary memory gives us a pretty good saving even now, but also means that the engine understands the concept of allocating things from a shared pool, and so is able to ask for the right amount once we change API.
    In another example, the new APIs would let us offload the work of creating command lists for the GPU onto multiple threads, but the engine previously had to do it single-threaded, so tasks were written in a way where one can depend on things that were done by the one before it. One of the sweeping changes that came through my code last year was that each piece of rendering work is now placed in a packet that can't see the others, in preparation for the work of filling and executing those packets being moved off-thread.

    Leave a comment:


  • Shevchen
    replied
    Originally posted by FishPls View Post

    The second link is probably more interesting, as there Dan explains why Dota 2 isn't the perfect showcase for Vulkan, and why DX9 is still a tad bit faster in not-drawcall-heavy scenes.
    Aye, watched it now... still hard to understand WHY DX9 is still faster (I know the draw calls don't saturate the bottleneck, but I still wonder, why the renderer itself is still faster than Vulkan)

    Leave a comment:


  • FishPls
    replied
    Originally posted by Shevchen View Post

    Thanks for the answer, watching it now.
    The second link is probably more interesting, as there Dan explains why Dota 2 isn't the perfect showcase for Vulkan, and why DX9 is still a tad bit faster in not-drawcall-heavy scenes.

    Leave a comment:


  • Jumbotron
    replied
    Wow! On Mad Max 1920x1080 normal you had a 5x speedup ! Very encouraging! Thanks for quick peek Michael!

    Leave a comment:


  • Shevchen
    replied
    Originally posted by FishPls View Post

    It's not a wrapper. Dan Ginsburg (the guy who mainly wrote the Vulkan backend in Dota 2) has been at many talks about Vulkan that you can find on Youtube. He has even commented on the Phoronix forums regarding Vulkan benchmarks a few times. Here's one such video https://www.youtube.com/watch?v=DWLkA6-wzj0 , here as well https://youtu.be/EX1RKhlOYmY?t=1h14m30s

    The Vulkan backend is just like the other render backends in Dota 2. The engine supports DX9, DX11, OpenGL and Vulkan all on the same level.
    Thanks for the answer, watching it now.
    Last edited by Shevchen; 01 April 2017, 06:59 AM.

    Leave a comment:


  • FishPls
    replied
    Originally posted by Shevchen View Post
    Awesome! Its getting more and more mature!

    Not sure why Open GL is still faster than Vulkan in Dota 2. Maybe Vulkan is again just a wrapper around the whole thing instead of being fully optimized?

    If yes, the industry needs to step up their game.
    It's not a wrapper. Dan Ginsburg (the guy who mainly wrote the Vulkan backend in Dota 2) has been at many talks about Vulkan that you can find on Youtube. He has even commented on the Phoronix forums regarding Vulkan benchmarks a few times. Here's one such video https://www.youtube.com/watch?v=DWLkA6-wzj0 , here as well https://youtu.be/EX1RKhlOYmY?t=1h14m30s

    The Vulkan backend is just like the other render backends in Dota 2. The engine supports DX9, DX11, OpenGL and Vulkan all on the same level.

    Leave a comment:


  • Azrael5
    replied
    this shows that if developers provide good software hardware can excel. That's what linux operating systems need to excel.

    Leave a comment:

Working...
X