141–150 of 207 posts
Earlier quoted context omitted.
Yeah, I've got a Libreboot'ed X200 and an X230 that I've Coreboot'ed+me_clean'ed. My desktops aren't in such good shape w.r.t. BIOS firmware though.
Talos using POWER is about the only option for us.
I hope AMD has something on their video chip line-up against nVidia as well. I'm curious if they knew nVidia was working on ray-tracing and plan to implement the same API or if they have some other tech they have up their sleeve they've been working on vendors with. I hate how nVidia has such a monopoly on the video chip market. Who knows, maybe Intel will finally get back into the gamer 3D market and we might finall…
By all accounts RTX delivers negligible visual improvement for games, for a huge performance hit. The technology is a lot more interesting in professional 3D modelling where light baking and rendering can be done much faster.
Mind you that you are seeing the early generation of hardware based real time raytracing now and it already can beat the quality of rasterization.
There is still a ton of room for improvements. One or two hardware generations from now we may finally see realtime generated images for which the term photorealistic is not just a silly marketing hype. They could truly fool you.
Earlier quoted context omitted.
It is not just about 32-core compute performance, if you compare a $385 threadripper motherboard + $650 CPU to the equivalent Intel competition, for single socket, the Threadripper is far ahead in terms of high bandwidth I/O. The threadripper has 64 PCI-Express 3.0 lanes direct to the CPU, for use with things like 25/40/100GbE network interfaces, or very large numbers of 10GbE interfaces. Or low-latency cluster inter…
They are direct to 1/2 of the CPUs, actually. This is part of what the GP was complaining about. The 2 dies which do not have memory also do not have PCIe wired out of the socket, so they are one hop away from I/O as well. If you are trying to max out I/O, you'd probably be better off with a low-end Epyc that had fewer cores enabled per die. It is interesting to note that the memoryless dies do have PCIe root ports,…
[1] https://www.servethehome.com/amd-epyc-infinity-fabric-latenc...
[2] https://forum.stanford.edu/events/posterslides/LowLatencyNet...
[3] https://gianniantichi.github.io/files/papers/pciebench.pdf
Earlier quoted context omitted.
Khronos is to blame by focusing too much on C, without convient tooling. CUDA had C, C++ and Fortran support since the early days, followed by the PTX bytecode format for any compiler vendor that wanted to support CUDA on their languages. It was necessary to loose the race for them to focus on C++ and come up with SPIR and SYSCL. And tools still seem not to be on par with what NVidia offers.
Khronos is a standards group. It's their job to make standards, not tooling. Individual vendors that are part of Khronos can make tooling.
Also regarding tooling, that isn't quite true, as they have engaged with LunarG for Vulkan, because they have learned from lack of OpenGL adoption, that the large majority of games developers wouldn't even bother without a proper SDK.
Earlier quoted context omitted.
What's disappointing is that none of the major cloud vendors has made any real commitments to AMD, at least none that I've seen. If speculative execution is a problem and you need to give each VM its own exclusive cores, great when you can source parts with 64+ cores on them!
AWS, Microsoft, Oracle, Packet... all have AMD shapes, in bare metal and VM to varying degrees. The list goes on and on. Oracle: https://www.amd.com/en/press-releases/2018-10-23-amd-and-ora... Azure: https://azure.microsoft.com/en-us/blog/announcing-the-lv2-se... AWS: https://aws.amazon.com/about-aws/whats-new/2018/11/introduci... Packet: https://www.packet.com/hardware/amd/
Earlier quoted context omitted.
Khronos is to blame by focusing too much on C, without convient tooling. CUDA had C, C++ and Fortran support since the early days, followed by the PTX bytecode format for any compiler vendor that wanted to support CUDA on their languages. It was necessary to loose the race for them to focus on C++ and come up with SPIR and SYSCL. And tools still seem not to be on par with what NVidia offers.
Khronos is a standards group. It's their job to make standards, not tooling. Individual vendors that are part of Khronos can make tooling.
Does 1.25x performance at the same power refer to clock speed? Does that mean that we can expect 5 Ghz in Ryzen 3000?
Earlier quoted context omitted.
My newly purchased Gigabyte B450M DS3H, says clearly 'Dual Channel Non-ECC Unbuffered DDR4, 4 DIMMs'. https://www.gigabyte.com/us/Motherboard/B450M-DS3H-rev-10#kf It also mentions that: >Support for ECC Un-buffered DIMM 1Rx8/2Rx8 memory modules (operate in non-ECC mode) Note the operate in non-ECC mode remark. Seems pretty clear to me. The CPU might allow ECC but now it's the motherboard playing tricks.
playing tricks as in not routing the extra lines
It was always the CPU that didn't have ECC, but now apparently your whole system has to be designed to be a fancy workstation.
Everybody keeps repeating AMD supports ECC out of the box, but the fact that you will most likely not have an AM4 motherboard which does have ECC enabled is new to me.
Earlier quoted context omitted.
Khronos is a standards group. It's their job to make standards, not tooling. Individual vendors that are part of Khronos can make tooling.
Then they made a bad standard to start with. Also regarding tooling, that isn't quite true, as they have engaged with LunarG for Vulkan, because they have learned from lack of OpenGL adoption, that the large majority of games developers wouldn't even bother without a proper SDK.
Nonsense. You'll be hard-pressed to find a platform that doesn't support C or a competent system design or even graphics design engineer who isn't confortable with C.
If their goal is to establish standards, they build upon standards.
Earlier quoted context omitted.
Then they made a bad standard to start with. Also regarding tooling, that isn't quite true, as they have engaged with LunarG for Vulkan, because they have learned from lack of OpenGL adoption, that the large majority of games developers wouldn't even bother without a proper SDK.
> Then they made a bad standard to start with. Nonsense. You'll be hard-pressed to find a platform that doesn't support C or a competent system design or even graphics design engineer who isn't confortable with C. If their goal is to establish standards, they build upon standards.
Likewise for game consoles, Windows and now Apple graphics APIs.
Defining standards does not mean they must provide a lowest denominator single implementation.
They can be defined in an IDL kind of way, like e.g. WebIDL, abstractly e.g. Internet RFCs, or define mappings to all major languages in the GPGPU field, namely C, C++ and Fortran.