Announcement

Collapse
No announcement yet.

AMD Smart Access Memory / Resizable BAR On Linux Still Ripe For Improvement

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

  • doomie
    replied
    Originally posted by QwertyChouskie View Post
    Here's the thing, SAM is more than just resizable BAR [rBAR] support, it's also the OS and driver support on both the CPU and GPU side to take advantage of the fast paths that rBAR support allows for. Although resizable BAR support itself doesn't have any real "special sauce", there is legitimate special sauce here: because AMD controls the CPU and GPU side of things, they can add the optimizations that rBAR support allows for to their driver and ensure/validate that it will work on ALL Ryzen 5000/RX 6000 setups. As seen here, any other setup is kinda a pig in a poke whether the mobo will support turning rBAR on, and even if you do, your OS and drivers may or may not support enabling the applicable fast paths allowed by rBAR support. So yes, SAM theoretically can be supported on many more systems than just Ryzen 5000/RX 6000 combos, but if you want SAM right now on Windows (majority of gamers), you do actually in all probability need the Ryzen 5000/RX 6000 combo. Us Linux nerds can take advantage of SAM on more setups, but we're the exception, not the norm.
    Thank you, this is what I heard from marketing: -Support for~. AMD could never promise support for other people's platforms, so how was their presentation supposed to be anything but exclusive? Clearly they're doing a bit of work, and results are that it's worth it. Imagine making good things negative. I'm just more and more glad I went AMD every day.

    Leave a comment:


  • QwertyChouskie
    replied
    Here's the thing, SAM is more than just resizable BAR [rBAR] support, it's also the OS and driver support on both the CPU and GPU side to take advantage of the fast paths that rBAR support allows for. Although resizable BAR support itself doesn't have any real "special sauce", there is legitimate special sauce here: because AMD controls the CPU and GPU side of things, they can add the optimizations that rBAR support allows for to their driver and ensure/validate that it will work on ALL Ryzen 5000/RX 6000 setups. As seen here, any other setup is kinda a pig in a poke whether the mobo will support turning rBAR on, and even if you do, your OS and drivers may or may not support enabling the applicable fast paths allowed by rBAR support. So yes, SAM theoretically can be supported on many more systems than just Ryzen 5000/RX 6000 combos, but if you want SAM right now on Windows (majority of gamers), you do actually in all probability need the Ryzen 5000/RX 6000 combo. Us Linux nerds can take advantage of SAM on more setups, but we're the exception, not the norm.

    Leave a comment:


  • skeevy420
    replied
    I like all these lake and fish names because now when our games freeze we can say we're stuck on a SAM-BAR

    Leave a comment:


  • kripteks
    replied
    Originally posted by user1 View Post
    Apparently, if you have "above 4g decoding" enabled in bios, that means you have resizable BAR support on Linux/AMDGPU. At least with ASUS, not all boards have this BIOS setting. I know that all or most ROG boards have this setting and some Prime boards have it as well, but my board (Prime Z390-P) doesn't have it.
    I have gigabyte b550 aorus pro with the lastest beta bios ("Add Re-size bar option for AMD Smart Access Memory support").
    I dont see amd sam option in bios, i have ryzen 3800xt , the "above 4g decoding" is here.
    With vega 56 last kernel rc and last mesagit "above 4g decoding" enabled and disabled have same result on unigine heaven 4.0 1920x1080/ultra/extreme/8x/fullscreen 72.x fps.
    Last edited by kripteks; 13 December 2020, 05:52 PM.

    Leave a comment:


  • szymon_g
    replied
    Could anyone explain it to me as if I was 5 what's the resizable bar etc? Why is it important?

    Leave a comment:


  • YummyHamster
    replied
    While I runned some testing on this yesterday using 2700x and a Vega64 I sa in my benchmarks that enabling this would just like in your benchmarks have a negative impact on the benchmarks for Vega. I'm curious why this is.

    Leave a comment:


  • tajjada
    replied
    Originally posted by artivision View Post
    You are a developer so filter you thoughts a little.
    Yes, my post was inappropriate. I already gave my apology.

    Originally posted by artivision View Post
    That is a PCIe future and Intel/NV may support it, doesn't mean that they will gain any performance.
    Oh yes they most likely will. If you look at the patches added to the Linux drivers, this allows removing unnecessary copies and buffering in system RAM. The driver can now directly output command buffers, etc., into GPU memory. This is something every GPU driver would benefit from.

    Leave a comment:


  • polarathene
    replied
    Originally posted by tajjada View Post
    That was then quickly debunked, with people showing that it is a standard PCIe feature (which was not really utilized until now) and NV/intel also saying that they will support it.
    That's the annoying thing with brand/marketing names to users I guess.

    Just the other day, someone was sharing tech advice to Windows users saying that for external USB SSD you need to go into settings and change the "USB eject protocol" (that they later called by official windows name of "Removal Policy" along with implying I was tech illiterate for some reason) from "Quick Removal" mode to "Best Performance". They insisted that gives you the real performance of the disk and that they noticed on Windows they would get 2x the performance vs macOS.

    Pointed out that the device was USB gen2x1 or gen1x2 probably and the macbook (separate device from the Windows OS) probably didn't have equivalent support, just USB 3 gen1x1. They insisted I shouldn't comment about things I don't know about (as I mentioned I was a linux user and not familiar with windows "Removal Policy").

    Looked up the MS docs, and "Best Performance" mode is not default for a reason, it enables write caching buffer, which if not safely removing/unmounting the storage device can result in corrupted data (even if a large video appears transferred on the OS and you can open/scrub through it fine, it's being read from memory during flush to disk at "Quick Removal"-ish speeds). Mentioned that in the comment thread so that other users would be aware of the actual risks that this user didn't seem to be aware of, then got blocked haha.

    Point is that the feature wasn't unique to Windows, it just had a more UX friendly approach where the user assumed it some magical Windows trick with no drawbacks. One of the things Windows does that confuses me IIRC, is it shows file size as GB when it's actually in GiB units, then users get confused why there 1TB disk they just bought and added was 931GB when viewed in the OS.

    If anyone is going to bring up the USB naming thing, it's actually good as-is. You just need to know USB 3.x with gen1 or gen2 and x1 or x2 lanes. Ignoring any other improvements you still have 3.0 (5Gbps), 3.1(10Gbps), 3.2(10-20Gbps). Each effectively falls back to the prior version if you don't meet the requirements. USB 4 however may not be compatible with 3.2 speeds even if it seems like sufficient bandwidth should be available, iirc it only has to offer 10Gbps data minimum to be USB 4 certified.


    Leave a comment:


  • tajjada
    replied
    Originally posted by bridgman View Post

    Even for the Windows users that the marketing folks were talking to, if you listen carefully what we said was that we would not be locking the functionality to that hardware but that for now our testing/fixing effort and commitment to make it work was for specific hardware.

    For Linux users, agd5f commented the same day here that the code would not be limited to specific hardware, and I made similar comments on other forums.

    Not sure how to view that as a "lie" but perhaps I'm missing something.
    During the announcement, the marketing was pretty clearly pushing the idea that SAM was a feature that consumers would specifically get by pairing the new GPUs with a latest-gen AMD CPU. The responses to that announcement on mainstream media (like Linus Tech Tips and other popular tech channels) were repeating that info (because they didn't know better), and talking about how it was interesting to see AMD applying some unknown platform-specific "magic sauce".

    The introduction of SAM was disingenuous and misleading *at best*.

    They could have made it clear that it could be an universal feature if it gains adoption, with AMD taking the lead by enabling it on the latest products. That would have been honest.

    I wasn't here (or on any Linux forums) to see the technical clarification. I only looked at the official announcement and popular tech media. I am sure this applies to a huge number of other people, especially Windows users.

    OK, that said, I apologize for the strong wording in my previous post. It was unnecessarily provocative. I guess I am spending too much time on youtube with its provocative clickbait. I got too emotional over this. I'll stop.

    Originally posted by ms178 View Post

    It was manipulative, sure. And they are abandoning their "honest PR" image they carefully built during the last three years.
    ...
    But they chose to implant the thought in people to get extra performance only with AMD + AMD hardware.
    Spot on. This is what angered me.

    Honestly, I love AMD for introducing SAM. If AMD didn't take that first step, nobody would know about the potential of this PCIe feature and it would have stayed unadopted. Thanks to AMD, now everyone wants it, and allegedly NVIDIA and Intel will be adding support, too.

    I just hate how it was presented / marketed.
    Last edited by tajjada; 13 December 2020, 05:25 PM.

    Leave a comment:


  • ms178
    replied
    Originally posted by tajjada View Post

    My point was that in their public announcement to the masses, they made it sound like it was some magical synergy between their latest generation of CPUs and GPUs. That was then quickly debunked, with people showing that it is a standard PCIe feature (which was not really utilized until now) and NV/intel also saying that they will support it.

    Of course, the technicalities are more subtle. Linux had support for these PCIe features for a long time. And I don't doubt that technical restrictions on Windows made it difficult.

    My point was that the initial mass marketing coming officially from AMD was misleading.And it led to the early announcement-day/launch-day media coverage amplifying that message.

    So yes, they lied.
    It was manipulative, sure. And it hurt their "honest PR" image they carefully built during the last three years. But I'd argue that there is a fine line between misleading, lying and just being manipulative with presenting selective info. AMD just didn't tell anyone in that anouncement that this feature has existed for years and could have been implemented on other platforms, too. If I were on their PR team, I would have come up with an honest story about implementing that feature on their latest platform and hinting to bring it also on other platforms with their competitors later though. You couldn't have made something wrong there, people would love you to bring more performance to the table, even more so for old hardware you already own. They still could have praised their latest and greatest platform for being validated for this and launching first with this feature. But they chose to implant the thought in people to get extra performance only with AMD + AMD hardware. That route clearly backfired with people like you who feel being mislead now. They should have reserved it for hardware features which are unique to their AMD + AMD platform, but SAM clearly wasn't that feature. [To AMD's credit, their developer was very honest in answering my question on that topic on the same day as bridgman mentioned in his comment above, I don't know if their engineers battled with their PR team over how to sell this feature, the next time I hope whoever argues for being more honest wins this fight internally.]
    Last edited by ms178; 13 December 2020, 05:11 PM.

    Leave a comment:

Working...
X