<davidlt[m]>
Looking at Computex footage, and I don't understand why folks are so interested in glass cases, RGB on the cables, fans, and even LCDs on the fans now!
<davidlt[m]>
Am I getting that old now? Because in most cases I will never gonna look at all that bling.
<davidlt[m]>
I am fine with paying higher amount for high-perf stuff, e.g. Noctua. I don't really care if it's brown, black, white, etc. It also has no RGB.
<davidlt[m]>
I feel like I am forced to pay for RGB and other stuff because folks think focusing on looks is important. I don't think PC is a form of art.
<davidlt[m]>
If I could I would do something similar as Linus (Linus Tech Tips). Rack in the basement and optical USB, DP, TB to the desk. That's cool, but also expensive.
<davidlt[m]>
Also PCI Gen 5 NVMes are crazy. There are a lot of heatpipes + large fin stack coolers for those.
<davidlt[m]>
I think we might need just to use immersion cooling.
<thefossguy>
At this point we should just switch to a rackmount case to cool all peripherals
<davidlt[m]>
Well, you don't want that next to your desk :)
<thefossguy>
I’m willing to deal with it.
<thefossguy>
I’ll probably keep it in a different room and SSH into it from a Pi
<davidlt[m]>
Hm. Looking as ASRock Hardware Unboxed video.
<davidlt[m]>
So removing crap from motherboard (Taichi) makes it 80-100 USD cheaper.
<davidlt[m]>
Like RGB, light reflective heatsinks, etc.
<thefossguy>
That’s a big jump
<davidlt[m]>
It seems that next Intel desktop CPUs will pull more power.
<thefossguy>
🙃
<davidlt[m]>
I think I saw from multiple motherboard vendors that they are adding more power stages.
<cwt[m]>
just clicked on the links and read commit messages, suddenly my smartwatch alert that my heart beating over 150bpm :-D
<davidlt[m]>
The newer generation of U74-MC has L2 prefetchers (which are not present in FU740 / Unmatched).
<davidlt[m]>
They are also configurable.
<davidlt[m]>
It's per-core block.
<thefossguy>
davidlt[m]: Ok that’s interesting
<davidlt[m]>
Technically you could set different settings for each core and even re-configure it for each apps (overkill).
<davidlt[m]>
I assume they tuned L2 prefetcher configuration.
<cwt[m]>
the L2 setting is in uboot, but can it be reconfigure in Linux after boot the kernel?
<davidlt[m]>
Yes, if you have access to that memory region.
<davidlt[m]>
The best option is to configure that at boot time.
<davidlt[m]>
Anything else is mostly overkill.
<cwt[m]>
<cwt[m]> "quite disappointed that it is..." <- ah... I know why they still based on 5.15.0, there is no progress on GPU driver (at least in public).
<cwt[m]>
I just upgrade my u-boot to use that L2 prefetcher, and then continue my kernel building. Hope it will be faster.
jcajka has joined #fedora-riscv
sharkcz has quit [Ping timeout: 240 seconds]
sharkcz has joined #fedora-riscv
foxtran has joined #fedora-riscv
<foxtran>
Hello!
<foxtran>
I'm trying to create chroot with Fedora on my Star64. I did it with supermin which I took from large image for HiFive unmatched (it works well). Unfortunately, after creating image for chroot, I have the problem since default /etc/yum.repos.d/fedora.repo contains metalink which does not work. Which metalink should I provide inside of fedora.repo?
<cwt[m]>
oh, new u-boot boot directly from my nvme
<davidlt[m]>
Yeah, it's in the release notes.
<foxtran>
It is interesting that /etc/yum.repos.d/fedora-riscv.repo is not provided by any package :|
<davidlt[m]>
Conan Kudo: There is an internal meeting IIUC which probably holds your answers.
<Eighth_Doctor>
internal to who?
<davidlt[m]>
Red Hat
<davidlt[m]>
Today
<davidlt[m]>
rwmjones|mtgs: mentioned this on the mailing list. Don't know the details.
<Eighth_Doctor>
that doesn't mean anything, since I'm not in Red Hat Engineering
<Eighth_Doctor>
he's going to know stuff, but I'll remain as clueless as if I wasn't a Hatter
<davidlt[m]>
Well, that's complicated :)
<thefossguy>
<Eighth_Doctor> "rwmjones: does this mean we're..." <- Do you mean to say release Fedora or RHEL for RISC-V in an official capacity?
<Eighth_Doctor>
yeah
<Eighth_Doctor>
at least I hope we're going to have Fedora RISC-V become official :)
<davidlt[m]>
NAK, we are still blocked by the hardware.
<davidlt[m]>
Well it isn't that far away.
masami has joined #fedora-riscv
foxtran has left #fedora-riscv [#fedora-riscv]
foxtran has joined #fedora-riscv
zsun has joined #fedora-riscv
masami has quit [Quit: Leaving]
<davidlt[m]>
I don't like this: Release: %{?autorelease}%{!?autorelease:22{?dist}}
zsun has quit [Quit: Leaving.]
jcajka has quit [Quit: Leaving]
<davidlt[m]>
I hope someone builds a fast SoC for javascript like Apple M stuff.
<thefossguy>
For what now?
<thefossguy>
Oh you mean for browsers
<thefossguy>
Fair then
<davidlt[m]>
Yeah.
<davidlt[m]>
Every time I need to use JIRA I feel like I need a new PC just for it.
<thefossguy>
I thought they had x86 mem layout. Didn't know they accelerated JS too.
<thefossguy>
I don't even know how they'd do the latter
<davidlt[m]>
Well, one thing is uarch.
<davidlt[m]>
Another thing is instructions. I think ARMv8 or v9 has some instructions to accelerate JS.
<thefossguy>
that's so cursed
<davidlt[m]>
I haven't done web-dev stuff, but IIRC everything is double in JS and thus there is a lot of conversions. There is an instruction for that now.
<davidlt[m]>
Another thing is memory ordering.
<davidlt[m]>
Fun fact, both of these features are coming to RISCV too.
<thefossguy>
Armv8.3-A has it. I'm amazed how you can speed up an interpreter. Like how... Do you poke in the process itself?
<thefossguy>
> Javascript uses the double-precision floating-point format for all numbers. However, it needs to convert this common number format to 32-bit integers in order to perform bit-wise operations. Conversions from double-precision float to integer, as well as the need to check if the number converted really was an integer, are therefore relatively common occurrences.
<thefossguy>
Ah, so that's how
<davidlt[m]>
Basically ARM CPUs have instruction just for javascript :D
<thefossguy>
davidlt, what _DO_ you do? I'm curious at the amount of knowledge you have :D
<davidlt[m]>
I am a swiss army knife, focusing mostly on distributions, porting, and related issues, I guess.
<thefossguy>
Damn
<thefossguy>
Amazing :)
<davidlt[m]>
BTW, Zicond was added as mandatory extension in RVA23.
<davidlt[m]>
Fun thing is that this started as a vendor extensions just recently, but very quickly was adopted within RVI, ratified, and incl. into RVA23.
<thefossguy>
People say we get fragmentation (which is fair and is probably true to a degree) but this is also an extremely nice benefit of RISC-V's structure/model. Vendors can actually contribute stuff they want to use in their own designs and the "community" tests it, alongside their own proprietary design.
<davidlt[m]>
To "handle" fragmentation we have higher-level specifications.
<davidlt[m]>
We will target what platform specs will tell us at some point.
<davidlt[m]>
It will define ISA and non-ISA SoC/CPU, platform, firmware interfaces, etc.
<thefossguy>
There will be minimal fragmentation in server and desktop. But "appliance machines" like routers 👀
<davidlt[m]>
Not a problem, there is RVM and RVB (that's a new thing).
<davidlt[m]>
RBM is for microcontrollers.
<davidlt[m]>
RVB is reduced RVA with less mandatory stuff.
<thefossguy>
s/routers/switch
<thefossguy>
my bad
<thefossguy>
I'll take a deeper look at RVM, that's new
<davidlt[m]>
That's old, but very few folks care about it.
<thefossguy>
Though, I think these appliances are just low powered (relatively speaking) cores with tonnes of accelerators :)
<davidlt[m]>
Well depends, some are really powerful.
<davidlt[m]>
It really depends on the feature set.