<clever>
sorear: i was looking into XIP, but then i discovered, risc-v xip requires an MMU, is there any reason for that, or did the kernel devs just choose to not implement it? i notice arm seems to have nommu xip
<sorear>
riscv xip is probably going away since riscv makes heavy use of ALTERNATIVE; making xip actually useful requires somehow representing all of the ALTERNATIVE information at compile time, which would be a lot of rarely used code in the build system
<sorear>
I don't know if this is the proximate cause of it requiring a MMU
hightower3 has quit [Ping timeout: 264 seconds]
<sorear>
you also can't do nommu/xip on riscv64 due to code model limitations unless ram and rom are <2GB apart
<clever>
sorear: i could see ALTERNATIVE being handled by just having a .text (rom) and .text.ram (ram)
<clever>
at the cost of having to copy certain functions over, the same way you copy .data over
<clever>
a lot of embedded platforms already do that, but instead because ram has lower latency and no cache-miss
<sorear>
the tooling implications of that are interesting
<sorear>
if you want to propose a patch before the deprecation takes effect next year, go ahead
<clever>
i assume xip mmu cheats, by just cloning things from rom->ram as needed, when it patches things?
<clever>
and the mmu hides that cheating
<sorear>
it could but there's probably a more boring reason like "the xip code makes assumptions about physical to virtual address conversion"
<clever>
i dont know of any hardware that would actually benefit from such a patch, i was more interested in just testing that part of linux, and having an example of how to make it work
<clever>
but since i lack an mmu, i cant realy test that
<sorear>
I'm mostly only interested in nommu linux for research/hobby prototypes (where adding a 1GB ram chip is ~free compared to any nonzero amount of coding time) and VMs (similarly weak constraints, and you can do KSM-type things on the host if you really care)
<sorear>
the best way to ensure that code is tested is to delete it.
<sorear>
no LOC, no bugs
<clever>
i also recently discovered, almost nothing implements the guest side of virtio2
<clever>
so qemu doesnt even have a way of turning virtio2 on
<clever>
so by your logic, we should just delete virtio2 support from linux? :D
<sorear>
do you mean host side?
<sorear>
if linux has support, that's the guest side
<clever>
linux supports the guest side of virtio1 and virtio2
<clever>
qemu supports both as well, but doesnt allow you to enable virtio2 without a patch
<sorear>
is virtio1 the same thing as virtio legacy?
<clever>
yeah
<sorear>
I thought I saw a "0.9" version somewhere once
<clever>
at the raw api level, there is a version register, that has a 1 or a 2 in it
<clever>
qemu defaults to version==1, and 2 is gated behind a patch
<clever>
the guest side can freely support both, and just detect what the host offers
<clever>
but the host cant detect what the guest supports and dynamically switch
<sorear>
if nobody is actually using it, and it's a nasty feature with cross-cutting effects on ~the entire kernel like xip is, then get rid of it
<clever>
ah yeah, its got very minor effects from what i can see
<sorear>
don't assume "no qemu support" = "no users"; there are other VMMs out there
<clever>
virtio1 expects all 3 ringbuffers to be contiguous in the physical space, you tell the host what page# it all starts at, and do pointer math to find each ring
Nixkernal_ has quit [Ping timeout: 260 seconds]
<clever>
virtio2 lets the guest use 3 seperate ringbuffers anywhere in guest ram, and uses 3 64bit pointers to tell the host where each begins
<clever>
as far as i know, there is no other differences, but i havent looked into legacy/1 much
<sorear>
iirc a big difference between legacy and modern virtio is that modern is designed to be used with a (virtual) iommu and don't assume everything is a physical address
<clever>
that is an optional feature, that the host/guest can negotiate
<sorear>
(without prejudice as to whether the "legacy virtio" I remember is the same as your virtio 1 or if it actually ever existed at all)
<clever>
it might be that a lot of those features are gated behind virtio2?
<clever>
oh right, i think legacy uses native byte order, and that gets hairy when you have a LE host and a BE guest, or a guest that switches endianness
<clever>
virtio2 demands LE for everything
Nixkernal has joined #riscv
<sorear>
that document uses the version numbers the way I remember, 0.9 for legacy, 1 for modern, apparently 1.1 and 1.2 exist now
<clever>
ah, ive just been using the raw value of the version register
eightthree has quit [Remote host closed the connection]
davidlt has joined #riscv
jacklsw has quit [Ping timeout: 260 seconds]
seasharp has joined #riscv
psydroid2 has quit [Ping timeout: 260 seconds]
aryeduino has quit [Remote host closed the connection]
eightthree has joined #riscv
psydroid2 has joined #riscv
hightower2 has quit [Ping timeout: 240 seconds]
paddymahoney has joined #riscv
Stat_headcrabed has joined #riscv
seasharp_ has joined #riscv
seasharp has quit [Ping timeout: 255 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #riscv
Stat_headcrabed has joined #riscv
Stat_headcrabed1 has joined #riscv
Stat_headcrabed has quit [Ping timeout: 264 seconds]
Stat_headcrabed1 is now known as Stat_headcrabed
troglodi1o has quit [Read error: Connection reset by peer]
vagrantc has joined #riscv
Andre_Z has joined #riscv
mlw has quit [Ping timeout: 252 seconds]
seasharp_ has quit [Read error: Connection reset by peer]
seasharp has joined #riscv
troglodito has joined #riscv
seasharp has quit [Client Quit]
seasharp has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
mlw has joined #riscv
<mps>
is the Bananapi BPI-F3 supported in mainline kernels
<mps>
i.e. "SpacemiT K1 8 core RISC-V chip" whatever it means
<courmisch>
no
<mps>
aha, thanks for info
<courmisch>
uh, is it so that when the ABI runs out of FA registers, it puts the floats in A registers? I would have tought they go to stack
<jrtc27>
yeah it's a bit quirky
<jrtc27>
the official wording is that when you run out of floating-point registers it's passed as if using the integer calling convention
<jrtc27>
"A real floating-point argument is passed in a floating-point argument register if it is no more than ABI_FLEN bits wide and at least one floating-point argument register is available. Otherwise, it is passed according to the integer calling convention."
<courmisch>
well, I guess it makes sense to put stuff in regs if possible
<courmisch>
maybe I should decree that FFmpeg does not support soft float ABIs. Nobody is ever going to use them
<courmisch>
but then again, now that we have the code to deal with them, might as well carry on
* jrtc27
shrugs
<jrtc27>
if you're using FFmpeg on a soft float microcontroller you're doing something wrong
<courmisch>
yes well, at least we don't support RV32E
<jrtc27>
if it's easier a compromise could be to fall back to the unoptimised C implementations?
<jrtc27>
(or maybe that's what you mean?)
<courmisch>
but a microcontroller with FPU would be using hardware float ABI anyway, wouldn't it?
<courmisch>
I thought the whole (questionable/dated) point of the soft ABI was to run-time detect the hardware float
<courmisch>
well anyway, that code requires Zve32f, which requires F
<courmisch>
okay I don't make sense. Obviously the soft ABI is necessary if there is no FPU.
BootLayer has quit [Quit: Leaving]
<sorear>
pre-ratification the ABI assigned argument registers in order and picked types after that, so void(*)(int, double) would take a0 and fa1
<sorear>
generally if you're using the soft ABI you'll also be using floating point emulation code which is provided as part of libgcc and compiler-rt
<sorear>
you could, in theory, runtime detect floating point, but the binary compatibility profiles all require D so there's little point
<sorear>
there could be demand for running ffmpeg-derived code on DSPs with F but not D; I don't know if you can cut ffmpeg per se down to a small enough code size for that or if realistic users would be using other projects possibly with copied code
f has joined #riscv
<courmisch>
in theory, FFmpeg can be cut down to many many small pieces, though not many people test that. For small devices doing audio, you'd probably use fixed-point
f has quit [Remote host closed the connection]
f has joined #riscv
<courmisch>
and then, that kind of hardware would more likely have no SIMD, or some vendor packed SIMD rather than Zve32{x,f}
f has quit [K-Lined]
hightower2 has joined #riscv
<sorear>
are there common codecs for which a correct fixed-point impl is possible but ffmpeg requires floats?
davidlt has quit [Ping timeout: 272 seconds]
<courmisch>
I don't know any codecs that can't be done in fixed-point, so probably any codec whose implementation is float only
<courmisch>
but we did notice that on x86 and RV, vector float is actually faster - as we don't have all the extra shift and rounding adds
<courmisch>
so motivation for maintaining the fixed point is not very high :/
<courmisch>
except for codec that are fundamentally fixed point, notably lossless ones