Announcement

Collapse
No announcement yet.

AMD Releases New Radeon Code: A-Sync DMA Engines

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

  • Rigaldo
    replied
    Good. I'm eager to see new benchmarks too. Hopefully there is a solid increase in performance(well, probably nothing groundbreaking, but visible).
    Still, I hope power management, which personally is my main concern, has significant improvements too.

    Leave a comment:


  • thegeek6
    replied
    Heck yes.

    One more feature, one more commit to make the free drivers superior.

    It's getting better all the time!

    Leave a comment:


  • artivision
    replied
    Originally posted by chrisr View Post
    This code is applicable to R600+ hardware! It's nice to see improvements being made for a very broad range of existing cards, rather than just the most recent generation or two.

    I wonder if there are any more such features waiting to be unlocked? (Apart from the UVD of course - we already know about that).


    Great start, becouse it's a start.

    Leave a comment:


  • chrisr
    replied
    But on the positive side...

    Originally posted by Deathsimple View Post
    So using it should result in some very nice performance improvements for certain use cases, but what Alex has released is just kernel part of the implementation, and even that is missing the CS checker. It will probably just take some more time till mesa really picks that up.
    This code is applicable to R600+ hardware! It's nice to see improvements being made for a very broad range of existing cards, rather than just the most recent generation or two.

    I wonder if there are any more such features waiting to be unlocked? (Apart from the UVD of course - we already know about that).

    Leave a comment:


  • Deathsimple
    replied
    The async DMA can do copy/moves independent of the shader engine. So while the shader part of the GPU is busy with the rendering we can still upload new data with the DMA at the same time.

    Additional to that it is quite a bit more efficient than the shader engine when you just want to copy some data from A to B, or just clear a specific region of memory (memcpy/memset).

    So using it should result in some very nice performance improvements for certain use cases, but what Alex has released is just kernel part of the implementation, and even that is missing the CS checker. It will probably just take some more time till mesa really picks that up.

    Cheers,
    Christian.

    Leave a comment:


  • fhuberts
    replied
    Originally posted by curaga View Post
    Does this alone have any performance impact? I recall Marek saying here ttm still does a sync after each transfer.
    It should have a very noticeable impact when buffer objects are moved and when VM mappings are changed.
    Especially the former case should have a rather big impact: the buffer move is performed by hardware, which is very fast at it. And if the buffer memory is not in coherent (cacheable) memory then the move is even faster.

    Leave a comment:


  • stalkerg
    replied
    WOW! Realy clean and understandable code with many comments! Thanks for all AMD team (for Alex special).
    Return to home and apply this pach for 3.7 ^_^ need testing OilRush fps.

    Leave a comment:


  • curaga
    replied
    Does this alone have any performance impact? I recall Marek saying here ttm still does a sync after each transfer.

    Leave a comment:


  • fhuberts
    replied
    Originally posted by przemoli View Post
    Yeah. I also would like to know what this "a" stands for. Thought that DMA is as "a" as you can get :P Or maybe its not about CPU/GPU chitchat but CPU DMA module to GPU DMA module talk?
    Looking at the code the a stands for Asynchronous.

    Or in other words: they have a DMA hardware engine on the GPU. This engine can transfer memory in parallel to other stuff happening. Hence they call is asynchronous. Logical, right? ;-)

    Leave a comment:


  • przemoli
    replied
    Originally posted by elanthis View Post
    A quick guess would be that they allow asynchronous DMA transfers.

    The specific consequence of which would be that a memory transfer to/from the GPU can be initiated without the driver needing to wait for it to complete, allowing reduced per-transfer latency and overall improved transfer bandwidth. That in turn should reduce draw call overhead, buffer update overhead, and texture upload overload, and hence improve performance for certain applications. For example, given the "GL is faster than D3D" benchmarks from Valve one can presume that their renderer is draw call bound, and hence this could offer a nice performance boost for Source games.

    All a quick guess, of course.
    Yeah. I also would like to know what this "a" stands for. Thought that DMA is as "a" as you can get :P Or maybe its not about CPU/GPU chitchat but CPU DMA module to GPU DMA module talk?

    Leave a comment:

Working...
X