<midfavila>
hey, question for anyone who has experience with the sifive or milk-v pioneer boards. are there any proprietary firmware binaries or out of tree linux drivers that i should know about before getting one?
<midfavila>
did a few google searches but didn't find much that was useful
Noisytoot has quit [Killed (erbium.libera.chat (Nickname regained by services))]
Noisytoot has joined #riscv
billchenchina- has quit [Max SendQ exceeded]
billchenchina- has joined #riscv
billchenchina- has quit [Read error: Connection reset by peer]
Noisytoot has quit [Excess Flood]
Stat_headcrabed has joined #riscv
Noisytoot has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
billchenchina- has joined #riscv
heidaren has quit [Remote host closed the connection]
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
billchenchina- has quit [Ping timeout: 255 seconds]
billchenchina- has joined #riscv
billchenchina- has quit [Remote host closed the connection]
heat has joined #riscv
stefanct has quit [Quit: quit]
stefanct has joined #riscv
coldfeet has quit [Remote host closed the connection]
davidlt has joined #riscv
<unlord>
courmisch: how do I land patches in ffmpeg?
<courmisch>
unlord: git send-email --thread
Andre_Z has joined #riscv
naoki has quit [Quit: naoki]
pecastro has joined #riscv
___nick___ has joined #riscv
___nick___ has quit [Client Quit]
___nick___ has joined #riscv
coldfeet has joined #riscv
jfsimon1981_b has quit [Remote host closed the connection]
jfsimon1981_b has joined #riscv
davidlt has quit [Ping timeout: 252 seconds]
pecastro has quit [Quit: Lost terminal]
Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #riscv
Tenkawa has joined #riscv
test924 has joined #riscv
coldfeet has quit [Remote host closed the connection]
Isaac_S has joined #riscv
<Isaac_S>
Hi everyone, quick question here (I'm still quite new to computer architecture and looking to understand some of the rationale behind the design decisions for RISC V. Been looking at primitive atomic operations, and I came across this quote in the RISC V ISA document:
<Isaac_S>
> "The Zaamo extension enables microcontroller class implementations to utilize atomic
<Isaac_S>
> primitives from the AMO subset of the A extension. Typically such implementations do not
<Isaac_S>
> have caches and thus may not be able to naturally support the LR/SC instructions
<Isaac_S>
> provided by the Zalrsc extension."
<Isaac_S>
Why would not having a cache make load-link/store-conditional atomic instructions not naturally supported? I thought that you'd want to make sure operations are atomic even in a uniprocessor system.
<palmer>
One way to implement LR/SC is by locking the cache line during the LR, that's how SiFive systems do it. So they probably mean you can't lock the cache line without a cache
<Isaac_S>
ohhhh, okay. That makes a bit more sense now.
Isaac_S has quit [Quit: Client closed]
<dh`>
there are other fairly trivial ways of supporting it on a uniprocessor
<dh`>
total cost should be one address register, one 1-bit register, a comparator for the address register, and a bit of access logic
<dh`>
you might not want that on a 50-cent microcontroller but "not be able to naturally support" is kinda baloney
<dh`>
and if you want to play fast and loose you might drop the address register, but that's not really recommended
<unlord>
courmisch: yeah, so none of this RVV 1.0 devices have hwprobe
<unlord>
can we please use HWCAP to detect V?
<unlord>
I'll write a patch
<courmisch>
that won't work because no kernel exposes B in HWCAP as of yet.
<unlord>
It is OK, V -> B on every device that exists
heat_ has joined #riscv
davidlt has joined #riscv
heat has quit [Read error: Connection reset by peer]
<courmisch>
that's only true on all 2 commercially available chipsets, not "every device that exists"
<courmisch>
AFAIR even QEMU added V before it added B
<unlord>
courmisch: do you know of any V hardware that does not support B?
<courmisch>
and I do remember Spike having V before B even existed
<courmisch>
I just added an hwprobe.h that just returns the correct values for my hardware. A simpler approach is to just force the stuff in CFLAGS (FFmpeg has detection for that)
<courmisch>
and besides B, some of FFmpeg's optimisations rely on fast unaligned, which will never be in HWCAP
<courmisch>
(or at least not the MISA-based parts of it)
<unlord>
as of qemu-9.0.1, qemu-user defaults to V and B on by default
<unlord>
courmisch: forcing things on in CFLAGS means that C code is built with those optimizations too
<courmisch>
of course. Correct solution is to use hwprobe, which is exactly what the code already does
<unlord>
what about all the hardware thath as V that does not have hwprobe?
<unlord>
seems like this will not be fixed for a long time
Tenkawa has quit [Ping timeout: 260 seconds]
<courmisch>
"official" solution from T-Head is to check the V bit and then ignore it if vendor ID is T-Head's and model ID is zero
<courmisch>
to do those checks from user mode, you need hwprobe...
<unlord>
and libavutil/riscv/cpu.c already falls back to HWCAP, so something is weirdly broken
<courmisch>
unlord: I suppose that your kernel headers have hwprobe and your kernel does not. Bad combo
<unlord>
isn't that something you can detect a runtime?
<unlord>
like, the syscall should fail
<unlord>
ffmpeg can be compiled on a different computer than it runs
Tenkawa has joined #riscv
coldfeet has joined #riscv
<courmisch>
that's why we have proper run-time detection according to the proper upstream kernel ABI
<sorear>
hwprobe is a sw feature, not a hw feature?
<unlord>
courmisch: do you prefer one patch at a time to the mailing list?
<unlord>
I've got a stack I'm working on
<unlord>
and --thread what?
<sorear>
if hardware is locked down enough that you can't install a 6.4+ kernel on it and the vendor isn't providing a kernel that new either, you probably shouldn't be using it
<unlord>
sorear: all hardware with RVV 1.0 comes with ancient kernels
<unlord>
I guess we should stop writing assembly for it?
<sorear>
the assembly would still be useful even if there were no commercial hardware at all
<sorear>
i wasn't aware that all RVV 1.0 hardware was DRMed and secure booted to the point that you *couldn't* install a non-obsolete kernel
<unlord>
sorear: the problem is that all the vendor bits are not upstreamed
<unlord>
I don't think anyone is preventing that from happening, just it is a bunch of work and will take an unknown amount of time to land
<sorear>
the starfive stuff took a year and change to land but you could apply the patches yourself at any point before that
<sorear>
and in a few months we'll be seeing wide availability of H extension hardware which makes it easier to run a current kernel
<sorear>
supporting pre-hwprobe kernels seems like a more shortsighted decision than supporting 0.7.1 (which _won't_ be fixed by a pure software update in a year), and we decided not to do the latter
<unlord>
sorear: but it looks like there is already support in libavutil/riscv/cpu.c
<courmisch>
you czn
<courmisch>
you can hack ffmpeg if you want. I think Alpine did it
<unlord>
I am too dumb to figure out how to send a patch :(
<courmisch>
but that's not something that should be upstreamed IMO
<sorear>
the support in cpu.c is correct, "V implies B" would not be
<courmisch>
welcome to embedded
<unlord>
thunderbird ate all the white space :(
<sorear>
there's active discussion on tech-p-ext about whether saturating multiply-add is needed by anything other than 3GPP
<sorear>
possibly relevant to ffmpeg
<courmisch>
I'd prefer gitlab over mailing list, but that's not my call.
<courmisch>
sorear: for packed SIMD?
<unlord>
courmisch: agreed
<sorear>
courmisch: not specific enough in this context. P ext = SIMD using integer registers
<courmisch>
I am not sure if anyone will care to fund P support in FFmpeg. The V is already mostly unfunded
<unlord>
hmm, did my mail make it?
<courmisch>
sorear: I don't recall a situation where I would have needed a saturated multiply-add, but it's not like I remember everything in the past 2 years, nor like I've surveyed everything
<courmisch>
unlord: if you're not subscribed, it went to mod