sorear[m] changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ending operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
<sorear>
good explanation
<muurkha>
it's possible jrtc27[m] used the word without knowing what it meant and was therefore honestly puzzled that it provoked such a reaction
<jrtc27>
all I meant was "that's a bit misleading"
<jrtc27>
I don't see why everyone needs to make such a thing of it and offer their own opinion and lecture
<jrtc27>
I get it, it wasn't the best choice of word, and I didn't appreciate that some people see it as a personal attack
<jrtc27>
but this reaction seems extremely overblown
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
hightower3 has joined #riscv
Gravis has joined #riscv
hightower2 has quit [Ping timeout: 245 seconds]
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs3 has joined #riscv
pabs3 has quit [Remote host closed the connection]
Gravis has quit [Quit: Murdered]
pabs3 has joined #riscv
Gravis has joined #riscv
Gravis has quit [Ping timeout: 260 seconds]
jacklsw has joined #riscv
Gravis has joined #riscv
handsome_feng has joined #riscv
MarvelousWololo has quit [Ping timeout: 260 seconds]
Gravis_ has joined #riscv
Gravis has quit [Ping timeout: 250 seconds]
Gravis_ has quit [Quit: Murdered]
Gravis has joined #riscv
Gravis has quit [Ping timeout: 245 seconds]
Gravis has joined #riscv
xypron has quit [Quit: xypron]
xypron has joined #riscv
EchelonX has quit [Quit: Leaving]
stolen has joined #riscv
zjason`` is now known as zjason
crabbedhaloablut has joined #riscv
wingsorc has quit [Remote host closed the connection]
<Tenkawa>
O_DIRECT speeds up buffered reads a lot though
<Tenkawa>
Easily hits 330+
<Tenkawa>
I am trying to figure out an initrd problem atm...
clonorizer has quit [Remote host closed the connection]
clonorizer has joined #riscv
<conchuod>
unlord: I posted about the issue you had the other day. I think there's a bigger mess behind that problem :)
<sorear>
which mess was that?
<conchuod>
How Linux internally tracks what extensions are supported.
jacklsw has quit [Remote host closed the connection]
vagrantc has joined #riscv
<gurki>
"tracks"? are you implying that it would keep track if i disabled avx2 for core 42?
<gurki>
(please ignore the clusterf... of actually implementing this :p)
<conchuod>
> How Linux internally tracks what extensions are supported.
<conchuod>
unlord's issue was that /proc/cpuinfo told them that vector was supported, but the kernel had not been built with vector support.
<unlord>
conchuod: bigger mess??
<sorear>
v is extra special sucky because even if it's in the dts and the kernel supports it, you might still get a sigill if the prctl knob is off
<conchuod>
It'll get FD wrong too, afaict.
Leopold_ has joined #riscv
Leopold has quit [Ping timeout: 240 seconds]
<courmisch>
wasn't there a setting for virtio to change some block size? or is that only for 9PFS?
<Tenkawa>
courmisch: in blockio (logical_block_size and physical_block_size)
<courmisch>
I mean, at least if you use 9PFS over virtio, QEMU whines by default that some size is too small and perf sucks
<courmisch>
but maybe that's just 9PFS
BootLayer has joined #riscv
<courmisch>
to set a build root up, I still find that a chroot with user QEMU over binfmt is better than soft-MMU/system QEMU
<courmisch>
but if you want V, you'll need hacks, as I don't think user QEMU exposes it in HWCAP yet
<unlord>
courmisch: that is probably what I need to do for compilation speed
jmdaemon has joined #riscv
<courmisch>
and so long as C910 is the best hardware for RVV, there is only so much that can be done
<unlord>
courmisch: is C910 still RVV 0.7.1 ?
<courmisch>
best is very relative here
<courmisch>
yes
<unlord>
courmisch: are you actually targeting 0.7.1
<courmisch>
yes and no. I run what benchmarks I can on 0.7.1 because I've nothing else
<gurki>
i think pretty much all rvv efforts are targetting 0.7.1 right now due to the lack of 1.0 hw
<courmisch>
I don't submit any 0.7.1 code to anywhere and I have no intentions to do so
<drewfustini>
Is the Sophgo SG2042 the same core?
<gurki>
which means that ppl are developing a lot of stuff in parallel right now since nobody pushes their stuff anywhere since 1.0 is supposed to be "the thing to use"
* gurki
isnt happy by the situation
heat has quit [Remote host closed the connection]
heat has joined #riscv
<gurki>
no, i dont want to imply i would have a good suggestion :(
alexghiti has joined #riscv
<courmisch>
I do submit the RVV 1.0 version of the code, functionally tested against QEMU
<courmisch>
but the atrocious perf of the segmented loads and stores are a huge problem for multimedia use cases. I think we've had that argument already.
KombuchaKip has quit [Read error: Connection reset by peer]
<gurki>
i did tune in occasionally, i dont remember an actual argument :3
<courmisch>
I mean argument in a generic sense, not necessarily disagreement as such
<gurki>
ah :)
KombuchaKip has joined #riscv
xypron has quit [Ping timeout: 245 seconds]
courmisch has quit [Quit: Reconnecting]
courmisch has joined #riscv
stolen has quit [Quit: Connection closed for inactivity]
<sorear>
drewfustini: to my knowledge yes
<courmisch>
the BSD daemon on my left shoulder tells me to disparage Alibaba's RVV implementation
<Tenkawa>
sorear: drewfustini: I looked it up.. its a 64 core C920, RVV 0.71)
<Tenkawa>
Sounds nice...
<gurki>
indeed :3
<courmisch>
is C920 not just C910 with vectors?
<courmisch>
either way, it does not sound nice to me
<drewfustini>
Thanks
<Tenkawa>
courmisch: Oh? why not (curious)
<courmisch>
because it's RVV 0.7.1 and it's not even good at it
<courmisch>
I'm not sure what's the use case for a 64-core system that has neither (proper) V nor H
<courmisch>
making a Debian buildd maybe, but that's rather niche
<Tenkawa>
Could it run Docker without V or H?
<Tenkawa>
If so I could see it being resourced out that way ...
<courmisch>
I could be wrong, but it sounds to me that they're just making a tech demo / prototype of their future many-core server designs. You know like VF1 vs VF2.
unsigned has quit [Quit: .]
<Tenkawa>
Not at that price point.. The RPI4 one they keep teasing maybe.... but this seems too risky to go all in on just for a tech demo / prototype
<Tenkawa>
(RPI sized one)
<courmisch>
but that's exactly my point: at such price point, I wouldn't want to buy a tech demo
<courmisch>
reminds me of the $5000 RISC-V laptop
<Tenkawa>
Oh something similar to the MNT Reform?
<Tenkawa>
That thing is... something
<Tenkawa>
(ARM Laptop built to order)
xypron has joined #riscv
xypron has quit [Ping timeout: 240 seconds]
clonorizer has quit [Remote host closed the connection]
clonorizer has joined #riscv
aburgess has joined #riscv
clonorizer has quit [Remote host closed the connection]
madge_ has joined #riscv
madge has quit [Ping timeout: 250 seconds]
xypron has joined #riscv
<sorear>
I think the relevant question is why Sophgo made the chip, since they're the only party with major NRE specific to sg2042; I have nowhere near enough insight into the Chinese domestic "AI" market to guess at that
<sorear>
I barely understand the English-language AI/ML bubble
xypron has quit [Ping timeout: 260 seconds]
<sorear>
docker doesn't need H or V. kvm _shouldn't_ but no one has put in the work to make mstatus.TVM actually useful
<sorear>
I would caution that not all application domains make as much use of segmented stores as ffmpeg does
<gurki>
64 cores with rvv sounds like the closest thing to a rv hpc thing we have rn
<courmisch>
I'd question the sanity of somebody investing in short-lived RVV 0.7.1 for HPC.
<courmisch>
That thing may be good if you need neither vectors nor hyp(e).
<gurki>
if youre even looking at segmented stores a vector extension with 64 cores probably isnt what youre looking for to begin with imho
<gurki>
being short-lived isnt that big of a problem for hpc, people port their code once and will keep running it with different inputs
<courmisch>
poor segmented perf is only one of many problems with RVV 0.7.1
<gurki>
im not saying theres not more problems, but i genuinely believe ffmpeg is a bad example for showing simd
<gurki>
intel had quite some fun getting it to work with avx512 at all, and intel (like them or not...) is really good at adapting software for their stuff
xypron has joined #riscv
<courmisch>
the most intensive bits like encoding and decoding can be offloaded to DSPs
<courmisch>
but you could make the same argument for crypto
<courmisch>
for graphics
<courmisch>
for AI/ML
<courmisch>
etc
<gurki>
i kinda want a raw performance linpack such as linpack, its my personal problem to evaluate whether i get enough flops per byte for this to make sense to begin with
<gurki>
(as a possible hint which kind of thing would make a gurki happy :) )
<gurki>
performance benchmark*
<gurki>
when i say "personal problem" i mean "i need to evaluate this for my specific application", this was bad wording.
<courmisch>
I still bet that RevyOS will pull the rug under RVV 0.7.1 support not very long after T-Head releases 1.0 hardware
<courmisch>
not to deny that there may be use cases where you need neither vectors nor hypervision. Buildd for instance
DoubleJ has joined #riscv
<courmisch>
it's simply too much work to maintain both versions at the same time, IME/IMO
DoubleJ has quit [Client Quit]
xypron has quit [Ping timeout: 260 seconds]
kaaliakahn has quit [Remote host closed the connection]
<sorear>
i still think it's kinda silly that software porting wasn't included in the pre-ratification work on the vector extension
DoubleJ has joined #riscv
xypron has joined #riscv
DoubleJ has quit [Client Quit]
clonorizer has joined #riscv
DoubleJ has joined #riscv
junaid_ has quit [Remote host closed the connection]
DoubleJ has quit [Client Quit]
DoubleJ has joined #riscv
<courmisch>
porting from RVV 0.7.1 to RVV 1.0? There was probably no code at that time, except for the examples in the spec though... ?
<gurki>
my point was that maintaining cycles in hpc are vastly different
<sorear>
porting from scalar to vector
xypron has quit [Ping timeout: 260 seconds]
<gurki>
people will use rvv 0.7.1 in hpc for the next 5-10 years if they manage to sell their stuff
<gurki>
(and if it happens to be reasonable hardware, which i am not qualified to comment on right now)
<gurki>
all it takes is them providing a reasonable math library with a good blas interface, honestly
<sorear>
H was co-developed with a KVM port. the IOMMU was apparently co-developed with a linux driver. the base GC ISA and psABI were ratified long after there were usable ports of debian, fedora, and freebsd
<courmisch>
if HPC uses matrices, the combination of slow segmentation and no vector-vector transposition is going to hurt even worse than FFmpeg
<courmisch>
I would imagine so at least
<conchuod>
That's the new rules innit, you need a PoC for ratification.
<sorear>
V was ratified with no compiler support and no known to me existing assembly code besides a couple of linear algebra kernels
<gurki>
as i said, im not qualified to rate their hardware. i was merely saying that ffmpeg might not be a good benchmark for hpc :)
<sorear>
HPC matrices have variable and large dimensions, so you can't really use segmentation or transposition for them, but large arrays of C99 or Fortran complex doubles will benefit from NF=2 segmentation
<courmisch>
H is a bit of a one-trick poney though. If you need to prove that it works, you need to implement a hypervisor with it
<courmisch>
but V could mean many very different things
<courmisch>
they would have spent a decade arguing what constitutes a good PoC for vectors
xypron has joined #riscv
<gurki>
yes there were quite some ... oppinions regarding which vector extension would be best
<sorear>
the hypervisor extension they were originally planning to ratify worked like ARM w/o VHE, was overtuned for type-1 hypervisors (Xen, VMware), and would have been a pain for KVM
<gurki>
i kinda left that discussionf or a while tbh
<sorear>
this was caught _because_ KVM development started before H ratification
<courmisch>
sorear: I suppose you mean ARMv8 w/o VHE
<courmisch>
ARMv7 VHE is very much like ARMv8 without VHE
<sorear>
there was also a seL4 prototype but it's dead code on a branch rn. idr if xen as well
<courmisch>
because Arm sucks at naming things
<courmisch>
do they use quaternaries in HPC?
<sorear>
courmisch: i mean that "privileged with H" and "privileged without H" were two different privilege levels with an entirely separate set of CSRs and would require ALTERNATIVEs for all of entry.S and everything that touches local interrupt state
<sorear>
quaternions? never seen them
<courmisch>
so it was type-2 but with different CSRs?
alexghiti has quit [Quit: Client closed]
<jrtc27>
more like textbook type 1 IIRC
<willy>
only took me 5 hours, but i got the Weekly Challenge Quordle in 8 guesses (3, 6, 7, 8)
<willy>
oops, wrong channel
clonorizer has quit [Excess Flood]
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #riscv
xypron has quit [Ping timeout: 260 seconds]
awita has joined #riscv
xypron has joined #riscv
wingsorc has joined #riscv
<sorear>
"all major applications ISAs move to a 32 register encoding" was not on my bingo card for the 2020s
BootLayer has quit [Quit: Leaving]
clonorizer has joined #riscv
heat has quit [Remote host closed the connection]
Leopold has quit [Ping timeout: 240 seconds]
Leopold has joined #riscv
Andre_Z has quit [Quit: Leaving.]
awita has quit [Remote host closed the connection]
mps has quit [Ping timeout: 246 seconds]
clonorizer has quit [Remote host closed the connection]