|
what would have been interesting would have been a radeon SSG setup. maybe this is a derivative
|
#
?
Jun 6, 2020 02:01
|
|
|
|
| # ? Jun 5, 2024 17:09 |
|
|
Malcolm XML posted:just slap em on a riser card if you must have x16, or do what servers do with x4 u.2 drives and just chain em all up i love u.2 in my servers so much lemme tell you 
|
|
#
?
Jun 6, 2020 02:06
|
|
|
WhyteRyce posted:You can't DMA to anything other than memory I thought like most other interfaces Yeah, but doesn’t that bypass the CPU, like op was asking for?
|
|
#
?
Jun 6, 2020 02:07
|
|
|
WhyteRyce posted:You can't DMA to anything other than memory I thought like most other interfaces the other important thing that you can DMA to is memory apertures, which is how PCIe peer-to-peer RDMA has always worked everyone on the bus agrees that address 000XXX-0Y000 belongs to the GPU and when you write to that memory "address" then you're really talking to the GPU instead in fact this is how all PCIe works, there is no protocol except RDMA really, you watch for when some flag bits get written and you know there's a message waiting for you
|
|
#
?
Jun 6, 2020 02:09
|
|
|
i don't know anything about this dude, but with the pants-making GBS threads on display here...wow...that must have been some come to jesus letter he got lmao
|
|
#
?
Jun 6, 2020 02:12
|
|
|
AARP LARPer posted:i don't know anything about this dude, but with the pants-making GBS threads on display here...wow...that must have been some come to jesus letter he got lmao Releasing a video slobbin on da PR knob like that months before the actual hardware gets into peoples hands to prove or refute the claims is worse than what he said initially imo Linus remains dumb as hell but I still find his stuff entertaining, even if its just in the trainwreck/talkin about computers with your dumb buddy kinda way.
|
|
#
?
Jun 6, 2020 02:24
|
|
|
Paul MaudDib posted:the other important thing that you can DMA to is memory apertures, which is how PCIe peer-to-peer RDMA has always worked It's been years since I was in that side but I thought, at the time at least, very few devices actually supported peer to peer transactions And in the case of nvme you still have to have something create and harvest the sq/cq which I'm not aware if devices other than the CPU can do anyway WhyteRyce fucked around with this message at 03:07 on Jun 6, 2020 |
|
#
?
Jun 6, 2020 03:03
|
|
|
WhyteRyce posted:It's been years since I was in that side but I thought, at the time at least, very few devices actually supported peer to peer transactions Depends on the domain. In the mid-2000s RDMA was all the rage for cluster networking even, with fibrechannel storage doing RDMA over Quadrics or Infiniband to another node’s RAM without CPU involvement on either side once the transfer was queued. (We don’t talk about the security model.)
|
|
#
?
Jun 6, 2020 03:07
|
|
|
Subjunctive posted:Yeah, but doesn’t that bypass the CPU, like op was asking for? The CPU is still very much involved in an NVMe read/write transfer even if the drive DMAs it into memory as far as my limited knowledge is aware
|
|
#
?
Jun 6, 2020 03:18
|
|
|
WhyteRyce posted:The CPU is still very much involved in an NVMe read/write transfer even if the drive DMAs it into memory as far as my limited knowledge is aware It’s involved in queueing the xfer op, sure, but does it have to do per-page work during the transfer or something?
|
|
#
?
Jun 6, 2020 03:29
|
|
|
WhyteRyce posted:It's been years since I was in that side but I thought, at the time at least, very few devices actually supported peer to peer transactions NVIDIA has supported it for a long time with GPU to GPU, GPU to storage, and GPU to Storage/GPU Across Infiniband. Those are the primary use-cases for GPUs. http://developer.download.nvidia.com/devzone/devcenter/cuda/docs/GPUDirect_Technology_Overview.pdf WhyteRyce posted:And in the case of nvme you still have to have something create and harvest the sq/cq which I'm not aware if devices other than the CPU can do anyway WhyteRyce posted:The CPU is still very much involved in an NVMe read/write transfer even if the drive DMAs it into memory as far as my limited knowledge is aware The GPU can very much initiate the request and receive the data without CPU intervention. That is the whole point of zero-copy stuff like Infiniband to reduce CPU utilization. The thing that is not trivial is knowing where to look. AFAIK most implementations of this (including Radeon SSG) use the SSD as a block storage and not a UFS or NTFS filesystem. Maybe maybe something like FAT32 that's dirt loving simple to implement even on a stupid GPU core.
|
|
#
?
Jun 6, 2020 03:34
|
|
|
Paul MaudDib posted:NVIDIA has supported it for a long time with GPU to GPU, GPU to storage, and GPU to Storage/GPU Across Infiniband. Those are the primary use-cases for GPUs. Oh interesting. queue manipulation is trivially easy so I guess I shouldn't be surprised they implemented it. Never dealt with a customer or a customer use case where this was called out But the Radeon SSG uses it's own onboard ssd right? So we aren't necessarily talking about the same situation as most people are assuming when we talk about this? WhyteRyce fucked around with this message at 05:58 on Jun 6, 2020 |
|
#
?
Jun 6, 2020 05:49
|
|
|
SwissArmyDruid posted:Um, ackshually, u.3 is the superior interface. 
|
|
#
?
Jun 6, 2020 11:27
|
|
|
karoshi posted:Also power. A fly-poop of silicon hardwired to a decompression algorithm is probably 3+ orders of magnitude more power efficient than a big fat OOO x86 core with it's uncore posse. Yeah I would think power would be the one of the more limiting factors that would decide against doing all the work with the x86 cores. Die space may be another. I supposed if AMD wanted to they could put some sort of hardware decompression block on the chipset or perhaps hang it off the IO die and connect it to the CPU or memory via IF bus but there hasn't been a peep of something like that coming down the pipe so don't get your hopes up.
|
|
#
?
Jun 6, 2020 13:42
|
|
|
WhyteRyce posted:Oh interesting. queue manipulation is trivially easy so I guess I shouldn't be surprised they implemented it. Never dealt with a customer or a customer use case where this was called out The Radeon SSG didn't have any special fast path between the GPU and SSDs, it just had a PLX switch to multiplex the three independent devices onto one PCIe slot. It was functionally the same as an Nvidia card talking to a physically seperate SSD over RDMA. It just seemed like a gimmick to me, and the fact they never followed up with an SSG2 based on Vega20 suggests the idea never really got any traction.
|
|
#
?
Jun 6, 2020 14:42
|
|
|
Seamonster posted:Post your AIDA64 numbers? Bit of a late followup, but finally have all 4 x 8GB sticks. Tightened the timings some more from 14-16-13-25-38 to 14-15-13-21-34 where it seems stable after running Karhu Ram Test for 45 minutes. AIDA64 seems in the ballpark looking at other 4 x 8GB numbers.   Learned an unamusing lesson: the board would simply not POST with 4 sticks though either of the 2 stick combos worked individually. Even tried at 2133MHz JEDEC settings, no dice with 4 sticks. Finally tried seating all 4 and resetting CMOS - it trained on the memory and no problems since. A side effect of non-QVL memory? v1ld posted:Is there any reason why putting an RX 5700 on a PCIe 4.0 slot would prevent me from overclocking its memory? This was from Vsoc being set to 1.15V. The OC runs fine at 1.0V, which value lets GPU VRAM be OCed again. Buildzoid made a random comment that higher Vsoc values can cause problems with PCIe 4.0 devices and that turns out to be true.
|
|
#
?
Jun 6, 2020 19:51
|
|
|
v1ld posted:Learned an unamusing lesson: the board would simply not POST with 4 sticks though either of the 2 stick combos worked individually. Even tried at 2133MHz JEDEC settings, no dice with 4 sticks. Finally tried seating all 4 and resetting CMOS - it trained on the memory and no problems since. A side effect of non-QVL memory? QVL doesn't matter usually, probably some setting that was wrong. If your sticks are dual rank, getting those to run at higher speeds can be pretty dicey if the wrong setting is set too high. To the memory controller, 4 dual rank sticks are like running 8 RAM sticks. Fame Douglas fucked around with this message at 20:01 on Jun 6, 2020 |
|
#
?
Jun 6, 2020 19:59
|
|
|
Has there been any rumors at all about Microsoft putting Ryzens into their Surface Pros?
|
|
#
?
Jun 7, 2020 02:48
|
|
|
Mostly just me begging. There's some speculation that the way that Microsoft handled the latest Surface Laptop refresh was to prepare for actually going in hardcore on AMD next gen.
|
|
#
?
Jun 7, 2020 03:26
|
|
|
I have a question, I have a 3700x on the way. Is the stock cooler going to be enough, as some people have told me, or should I spring for an aftermarket one? My roommate has a GameCube sized Noctua and I was considering it.
|
|
#
?
Jun 7, 2020 07:58
|
|
|
It's fine, unless you are running into airflow constraints with a small form factor case it is more than adequate.
|
|
#
?
Jun 7, 2020 08:40
|
|
|
I'm running the stock cooler on my 3600X and it's doing just fine with temps.
|
|
#
?
Jun 7, 2020 08:55
|
|
|
It's going to be louder than a NH-D15 (which is pretty much the best air cooler there is), but I'd first try stock at least. I'm running my 3800x with a NH-U14S, which is the half-gamecube size version of the cooler your roommate has - very happy with it. If you're more on a budget but want a better cooler, a cheaper tower cooler would be the Hyper 212 EVO (they now all come with AM4 brackets, contrary what their website says).
|
|
#
?
Jun 7, 2020 08:56
|
|
|
Cage Kicker posted:I have a question, I have a 3700x on the way. Is the stock cooler going to be enough, as some people have told me, or should I spring for an aftermarket one? My roommate has a GameCube sized Noctua and I was considering it. I'd get a decent $30-40 tower that has a bit more mass and moves air backwards towards the rear exit fan, instead of straight upwards diffusing it everywhere in the case. You don't need a huge chonker for a stock 3700 though.
|
|
#
?
Jun 7, 2020 13:24
|
|
|
.
sincx fucked around with this message at 05:50 on Mar 23, 2021 |
|
#
?
Jun 7, 2020 19:57
|
|
|
sincx posted:as long as you have a 120mm exhaust fan above the I/O shield, the stock cooler is more than sufficient if you aren't overclocking (and overclocking the ryzen 3000 series is sorta pointless) Being pedantic here but OCing the core is near pointless, but loving around with memclocks and fabric clocks are another thing. I think that's going to be true for a long time unless Zen4 can somehow dynamical clock the memory and fabric clocks on its own.
|
|
#
?
Jun 8, 2020 07:03
|
|
|
.
sincx fucked around with this message at 05:50 on Mar 23, 2021 |
|
#
?
Jun 8, 2020 07:14
|
|
|
Latest beta of HWiNFO shows if mb is misreporting power to improve benchmarks: https://www.hwinfo.com/forum/threads/explaining-the-amd-ryzen-power-reporting-deviation-metric-in-hwinfo.6456/
|
|
#
?
Jun 9, 2020 18:58
|
|
|
Anyone else seeing what looks like a reduction in performance in Windows 10 build 2004 versus 1909? I haven't thoroughly looked into it yet, but since running the update my CPU-Z benchmark is a little lower and I seem to be taking a small hit in fps in games.
|
|
#
?
Jun 9, 2020 23:23
|
|
|
Do you have Hyper-V enabled now whereas you didn't have it enabled before (enabling Memory Isolation in Defender activates Hyper-V as well, as does Sandbox, WSL2 or Application Guard)? That tends to reduce performance by a bit
|
|
#
?
Jun 10, 2020 00:08
|
|
|
Fame Douglas posted:Do you have Hyper-V enabled now whereas you didn't have it enabled before (enabling Memory Isolation in Defender activates Hyper-V as well, as does Sandbox, WSL2 or Application Guard)? That tends to reduce performance by a bit I'll check when I boot back into Windows later tonight. Thanks!
|
|
#
?
Jun 10, 2020 00:23
|
|
|
v1ld posted:Latest beta of HWiNFO shows if mb is misreporting power to improve benchmarks: https://www.hwinfo.com/forum/threads/explaining-the-amd-ryzen-power-reporting-deviation-metric-in-hwinfo.6456/ Anandtech/Ian Cuttress came out with an article about this because the Tom's Hardware coverage was kinda sensationalist/alarmist: https://www.anandtech.com/show/15839/electromigration-amd-ryzen-current-boosting-wont-kill-your-cpu As far as I understand it, whereas Intel has the PL1/PL2/Tau settings, and then motherboard manufacturers increase those settings above Intel's recommendations to make CPUs boost for longer, what motherboard manufacturers do with AMD is to... I don't have a better word for it besides misrepresent - they misrepresent the Package Power Tracking metric to be lower than it really is, so that the AMD CPU will boost for higher/longer (assuming the other two limits that define boosting, thermals and current, haven't yet been hit). On the one hand, this does mean that people might have their CPUs running hotter than they might expect, if they were looking at their thermals relative to the reported wattage, and it doesn't seem like a good idea for your motherboard metrics to be not giving you "real" numbers. On the other hand, Techpowerup was suggesting that this sort of behavior was going to lead to CPUs dying out or having their lifetimes severely reduced, which is a pretty big exagerration. If I'm not mistaken, even if somehow your cooling solution was only just barely good enough for your CPU, this still wouldn't be a problem because the CPU would just downclock/not-boost to stay within thermal limits, and the increased current would never be enough to endanger the CPU by itself. Still, it's good that the HWinfo has managed to find a way to report the number accurately. gradenko_2000 fucked around with this message at 10:55 on Jun 10, 2020 |
|
#
?
Jun 10, 2020 08:31
|
|
|
Motherboard manufacturers have been quietly increasing their default voltages for Intel CPUs above what Intel recommends for a long time, this is type of behaviour is (unfortunately) a very old hat.
|
|
#
?
Jun 10, 2020 09:05
|
|
|
Fame Douglas posted:Motherboard manufacturers have been quietly increasing their default voltages for Intel CPUs above what Intel recommends for a long time, this is type of behaviour is (unfortunately) a very old hat. Right - I think the difference in this case is that since AMD doesn't have the kind of out-of-the-box configurable settings that Intel does, and instead relies on taking certain measurements to check whether a CPU is allowed to boost, the manufacturers then get around it by spoofing (one of) the measurements entirely.
|
|
#
?
Jun 10, 2020 09:47
|
|
|
gradenko_2000 posted:On the one hand, this does mean that people might have their CPUs running hotter than they might expect, if they were looking at their thermals relative to the reported wattage, and it doesn't seem like a good idea for your motherboard metrics to be not giving you "real" numbers. Yeah, it seems like modern CPUs/GPUs have a lot of protections built in when it comes to preventing damage to themselves from overly aggressive boosts. My thought was your latter point - there's a lot of code in these things to optimize behavior across load / power / thermals and misrepresenting power seems like a bad idea when the general consensus is that AMD is not leaving much on the table to further optimize to begin with. Hopefully the availability of these numbers in HWiNFO will drive more accurate power reporting in the future.
|
|
#
?
Jun 10, 2020 13:13
|
|
|
Fame Douglas posted:Motherboard manufacturers have been quietly increasing their default voltages for Intel CPUs above what Intel recommends for a long time, this is type of behaviour is (unfortunately) a very old hat. The default voltage on my Asus z170 board was something so absurd that I was able to run an offset in the -.3 range even with a pretty hefty overclock.
|
|
#
?
Jun 10, 2020 13:23
|
|
|
It's great just how much logic is present in cpus/gpus/boards to optimize behavior for current conditions. Obviously that code isn't perfect and it's an extremely gnarly optimization problem with a huge number of variables, but I still feel better about those decisions being made at the point where more complete information is available that by just pushing up one parameter ignoring all else. One feature of the Buildzoid OC for the PVS memory I followed is that he only specifies a very few voltages (Vdimm, Vsoc, Vvddg ccd/iod) and most of the timings. He leaves all other parameters to auto, including every parameter who unit is Ohms, with the comment that the existing code does a good job of optimizing these already. I like that - it's locking down some parameters to narrow the search space for an optimal solution and then letting the code get on with the solution. No doubt someone can come up with a better manual solution, but as long as auto is at most a few points off...
|
|
#
?
Jun 10, 2020 13:45
|
|
|
An update on my experience with Windows 10 build 2004: I was lazy and did nothing and my last benchmarks were better. I suspect it may have been indexing after the update and that was dragging the performance down.
|
|
#
?
Jun 11, 2020 21:18
|
|
|
Jim Keller has left Intel: https://wccftech.com/exclusive-intel-internal-memo-jim-keller-departure-new-structure/
|
|
#
?
Jun 12, 2020 00:53
|
|
|
|
| # ? Jun 5, 2024 17:09 |
|
|
did he complete an architecture design/revamp? "effective immediately" 
|
|
#
?
Jun 12, 2020 02:03
|
|
