dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
leah2 has quit [Ping timeout: 258 seconds]
Entei[m] has joined #fedora-riscv
leah2 has joined #fedora-riscv
iooi has quit [Quit: iooi]
<davidlt[m]> Morning 🌄
<davidlt[m]> I will attempt to quickly cook new disk images with v6.3.11 today before v6.4 arrives.
<davidlt[m]> BTW, Firefox finally compiled 🔥
drewfustini has quit [Ping timeout: 240 seconds]
drewfustini has joined #fedora-riscv
esv_ has joined #fedora-riscv
esv_ has quit [Ping timeout: 246 seconds]
<davidlt[m]> Have no recommendations right now, just started watching some.
<davidlt[m]> This is nothing new, but some might still don't know this.
<davidlt[m]> It will explain why not all PCIe cards will work on riscv64 systems, because PCIe also incl. x86_64 binary firmware.
<davidlt[m]> Basically you need to emulate x86_64 on your host (aarch64, riscv64) [thanks to QEMU TCG] to run that early firmware blobs on the card.
<davidlt[m]> That's of course on UEFI firmware (Tianocore EDK2).
<conchuod> Jeremy Bennett is a good speaker
<davidlt[m]> I am on the Android now: https://www.youtube.com/watch?v=xLwdUn3DQp8
<davidlt[m]> It's nice to see RISE being mentioned in videos :)
<davidlt[m]> I want to know if they picked baseline ISA for Android.
<davidlt[m]> He said it!
<davidlt[m]> RVA22 mandatory or optional extensions ;)
<davidlt[m]> At around ~4:30 in the video.
<conchuod> davidlt[m]: Is it worth watching though?
<davidlt[m]> Well, I listen to them instead of music right now.
<davidlt[m]> Watching not really.
<davidlt[m]> I was thinking Whisper AI + GPT4 for summary would be enough :D
<conchuod> All the titles are very $marketingstatement
<davidlt[m]> Yes they are.
<davidlt[m]> That's why I have never been at RISCV Summit (any).
<davidlt[m]> The amount of really interesting content is low. The most exciting part is meeting folks there, I guess.
<conchuod> I am not sure that "exciting" is the word for that, certainly not for 97.5% of the attendees.
<conchuod> The LLVM talk from Alex should be good
<davidlt[m]> at ~17 minute mark he again talks about RVA22 + probably vector + vector crypto
<davidlt[m]> explains kinda why scalar crypto is not an option in RVA23
<davidlt[m]> Actually he as a few places with "probably". So they thinking a lot about RVA22.
<conchuod> Ye, Alex's one is worth it if you aren't super up to date on LLVM RISC-V stuff
<davidlt[m]> Ah next slide, what's next after rva22 + vector + vector crypto :)
<davidlt[m]> That looks like RVA23 at the 1st glance.
<davidlt[m]> rwmjones: are you up for doing more compile benchmarks on VF2?
<davidlt[m]> From Mark H. talk:
<davidlt[m]> This kinda shows that Android Features are post RVA23 :)
<davidlt[m]> What the hell is "Public Name X"? :)
<davidlt[m]> Isn't RVAXY already that name?
<rwmjones> davidlt[m]: hey
<rwmjones> sure
<davidlt[m]> It basically shows that post-RVA23 (RVA24?) is a major thing.
<rwmjones> kernel huh :-?
<rwmjones> actually maybe llvm is worse
<rwmjones> anyway yes, I'll set one of them off
<davidlt[m]> Those both take similar time to build.
<davidlt[m]> The last one will be GCC ;) But that's later.
<rwmjones> looks like about 14 hours?
<rwmjones> 15 hours for llvm
<davidlt[m]> Yeah, so should be 8-10 hours on VF2.
<davidlt[m]> At least I expect that.
<rwmjones> I'm just doing $ time rpmbuild --rebuild llvm-16.0.5-1.0.riscv64.fc38.src.rpm
<davidlt[m]> ok
<rwmjones> cmake will automatically do parallel builds IIRC?
<davidlt[m]> Yes
<davidlt[m]> rwmjones: just remember to disable tmpfs for /tmp
<rwmjones> yeah I did that
<rwmjones> btw, "interesting" TCG bug:
<rwmjones> I'm not sure to what extent it affects riscv because its to do with self-modifying code
<rwmjones> & (I assume) riscv forces you to explicitly flush the i-cache
masami has joined #fedora-riscv
kalev has quit [Quit: leaving]
masami has quit [Quit: Leaving]
<rwmjones> llvm is @ 730/2932
<davidlt[m]> Nice
<davidlt[m]> Do you monitor memory usage?
<rwmjones> not explicitly but ...
<rwmjones> total used free shared buff/cache available
<rwmjones> Mem: 7925 687 4079 17 3158 7136
<rwmjones> Swap: 0 0 0
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<conchuod> > & (I assume) riscv forces you to explicitly flush the i-cache
<conchuod> Far from an expert on these kind of things rwmjones , but for Linux at least we do icache maint. for code patching.
<conchuod> The ISA is pretty bad about these kinds of things though, there's been a few "discussions" about it on LKML ;)
<rwmjones> conchuod: yeah indeed we do, we do a "self-iret" thing
<rwmjones> (or SERIALIZE for intel cpus that support it, but I think that's very recent)
<rwmjones> however the problem here is really with TCG itself
<rwmjones> another core (TCG thread) is retranslating the code before the write happened
<rwmjones> it sees the old memory contents and so translates it to the old code (using int3)
<rwmjones> and then because we never invalidate the TB again, we always run the wrong code
<rwmjones> the iret doesn't really help (unless we invalidate every TB which would be slow)
<rwmjones> talking about it though, I might see if a patch which does invalidate every TB on iret actually fixes the problem ...
<rwmjones> it will at least confirm the theory is correct
zsun has joined #fedora-riscv
<rwmjones> the answer is that calling tb_flush (on sync_core) absolutely kills performance, so much so that the guest barely makes progress
zsun has quit [Quit: Leaving.]
<conchuod> No progress, no races.
<conchuod> Seems like a fix to me
dtometzki is now known as dtometzki__
esv has quit [Remote host closed the connection]
iooi has joined #fedora-riscv
<rwmjones> ..
<rwmjones> llvm is @
<rwmjones> 2603/2932
esv has joined #fedora-riscv
<davidlt[m]> Heh, this actually might finish today.
<sorear> a little bit concerned every time I see a slide that implies the author thinks profiles will be monotonic forever
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
<rwmjones> llvm is doing RPM stuff ...
<rwmjones> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
<rwmjones> Recommends: llvm-debugsource(riscv-64) = 16.0.5-1.0.riscv64.fc38
<rwmjones> Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/rjones/rpmbuild/BUILDROOT/llvm-16.0.5-1.0.riscv64.fc38.riscv64
<rwmjones> writing rpms ..
<rwmjones> llvm-16.0.5-1.0.riscv64.fc38:
<rwmjones> real601m41.466s
<rwmjones> user2193m5.753s
<rwmjones> sys95m42.081s
<rwmjones> I'm doing the kernel now ...
<rwmjones> $ time rpmbuild --rebuild kernel-6.3.11-200.0.riscv64.fc38.src.rpm
<rwmjones> 601m is 10 hours
<rwmjones> but my feeling is that it was very fast apart from the serialized RPM bits at the end
<rwmjones> (ie amdahl's law, again)
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv