KombuchaKip has quit [Read error: Connection reset by peer]
KombuchaKip has joined #riscv
<cousteau>
Why do all the profiles in riscv-profiles/profiles.adoc mention "and is little-endian"? Is there any RV arch that is bi-endian (or plans for it)?
<cousteau>
(I guess there won't be big-endian, but maybe bi-endian is a possibility. I don't see the point though.)
<sorear>
all RV arches are potentially big-endian or bi-endian
Armand has joined #riscv
naoki has joined #riscv
mlw has joined #riscv
mlw has quit [Ping timeout: 252 seconds]
jacklsw has joined #riscv
Armand has quit [Ping timeout: 252 seconds]
Tenkawa has quit [Quit: Was I really ever here?]
EchelonX has joined #riscv
jmdaemon has quit [Ping timeout: 264 seconds]
cousteau has quit [Remote host closed the connection]
cousteau has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat_ has quit [Remote host closed the connection]
heat_ has joined #riscv
JanC has quit [Ping timeout: 264 seconds]
JanC has joined #riscv
johnmcnuggets has quit [Ping timeout: 255 seconds]
davidlt has joined #riscv
davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
mlw has joined #riscv
marcj has joined #riscv
MaxGanzLaptop2 has joined #riscv
MaxGanzLaptop2 has quit [Remote host closed the connection]
MaxGanzLaptop2 has joined #riscv
BootLayer has joined #riscv
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
ezulian has joined #riscv
junaid_ has joined #riscv
junaid_ has quit [Quit: Lost terminal]
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
zjason` is now known as zjason
crossdev has joined #riscv
ezulian has quit [Quit: ezulian]
junaid_ has joined #riscv
ezulian has joined #riscv
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #riscv
jacklsw has quit [Ping timeout: 260 seconds]
naoki has quit [Quit: naoki]
crossdev has quit [Ping timeout: 260 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
hightower3 has joined #riscv
hightower2 has quit [Ping timeout: 264 seconds]
BootLayer has quit [Quit: Leaving]
junaid__ has joined #riscv
junaid_ has quit [Ping timeout: 252 seconds]
Leopold has quit [Quit: No Ping reply in 180 seconds.]
Leopold has joined #riscv
murgeljm has joined #riscv
junaid__ has quit [Remote host closed the connection]
<palmer>
ardb: I'm not sure exactly what you're asking
raym has quit [Ping timeout: 264 seconds]
<palmer>
(also our kernel meeting is in like 1 minute...)
raym has joined #riscv
<palmer>
so the question is about this "However, I don't think the EFI stub can use GP - please refer to my other reply." part? I don't think we wrote that down
johnmcnuggets has quit [Ping timeout: 272 seconds]
justache has quit [Remote host closed the connection]
justache has joined #riscv
<ardb>
palmer: the EFI stub runs as a EFI application in the context of the firmware
<ardb>
at the same privilege level as the firmware itself
MaxGanzLaptop2 has quit [Remote host closed the connection]
<ardb>
the calling convention suggests that GP should be left alone, and the EFI spec says that GP should not be used at all
MaxGanzLaptop2 has joined #riscv
<palmer>
ya,I'm just reading that
<ardb>
so the adventurous way to interpret that is that the EFI stub can use GP because the firmware should not use it at all
<palmer>
ya, what does "UEFI firmware" mean?
<ardb>
the last thing that runs before the kernel on a EFI system
<palmer>
and the stub is in the kernel, so it's not part of firmware? that's how i'd interpret it
<ardb>
no it is not part of the firmware, but initially, it runs inside the firmware context as a EFI application
<ardb>
just like GRUB, for instance
<ardb>
or systemd-boot
BootLayer has quit [Quit: Leaving]
<xypron>
ardb: and it might return to the firmware on error.
<palmer>
OK (sorry, I don't really know the EFI terminology)
<ardb>
right
<sorear>
my preferred interpretation of the ABI is that gp is reserved to the "main application", whatever that means in a given context, but I have only a passing familiarity with EFI
<ardb>
xypron: yes, and it might even take timer interrupts in the firmware
<xypron>
ardb: I think this should be clarified in the UEFI specification.
mlw has quit [Ping timeout: 264 seconds]
<ardb>
sure
<xypron>
U-Boot conserves gp when calling the EFI application.
<palmer>
the line in the spec is pretty bold: "UEFI firmware must neither trust the values of tp and gp nor make an assumption of owning the write access to these register in any circumstances"
<palmer>
I think a maximal interperation of that would be that firmware can't even write gp/tp (even if all the save/restore on transitions is there)
<ardb>
indeed
<ardb>
my ca utious interpretation of that would be to never use GP at all in EFI code
<ardb>
since the GP based symbol references seem like optimizations rather than anything essential
justache has quit [Remote host closed the connection]
<palmer>
in general GP is an optimization, but sometimes embedded stuff uses it for tricky access patterns (it essentially gives you another memory region to access that you can put anywhere)
<ardb>
paragraph 2.3.7
justache has joined #riscv
<palmer>
I'd make the EFI spec allow firmware to save/restore GP, I think maybe that was the intent of the language there but I wouldn't read it that way
<palmer>
either way, I think the kernel (and EFI stub) are safe to touch GP
<xypron>
IIRC that UEFI statement was put in to indicate that the EFI applications may change gp, tp.
<sorear>
the relevant questions are under what circumstances EFI applications are allowed to switch stacks and perform EFI firmware calls in possibly reentrant interrupt contexts
<palmer>
xypron: ya, I think that's a reasonable thing to do. It's just that saying "applications may trash gp/tp" is different that saying "firmware can't trust gp/tp" -- maybe if it says "firmware can't trust gp/tp at application transition boundaries" it'd be the same, but it's different ;)
<ardb>
whoa that didn't even occur to me - i was thinking about returning from the EFI stub, or taking timer interrupts, but of course, this applies to EFI boot service calls as well
junaid_ has joined #riscv
<sorear>
> See Links to UEFI Specification-Related Documents (https://uefi.org/uefi) under the heading “RISC-V EFL psABI Specification”
<palmer>
OK, I sent at least that first bit
<ardb>
but if we can avoid relying on GP to begin with, this whole problem goes away, no?
<sorear>
this seems to be a dead reference?
<palmer>
sorear: ya, there's some broken links in there (the "Detailed Calling Convention" stuff points to arm32, for example)
<palmer>
ardb: ya, avoiding GP is usually the best bet ;)
<palmer>
if you don't want GCC to generate GP-relative references, just don't define `__global_pointer$`
<sorear>
EFI needs to guarantee that gp and possibly tp have their application values on callback entries for it to be fully useful, I'm trying to find anything relevant in the main EFI spec on callbacks/interrupts/reentrancy discipline
<ardb>
palmer: that is what we implement today, but the poster is taking that out but without explaining why GP is needed to begin with
<palmer>
it's via `-mno-relax` currently, which is a bit heavier-weight, but ya
<ardb>
palmer: yes that is what we use today
<palmer>
I don't get the "gcc-13 uses GP" argument, nothing should have changed there. So maybe that's the core of the problem?
<conchuod>
I just wish there was a rationale given for the two reverts (and a cover letter would be nice!).
<conchuod>
ardb: hmm, that dude is our ACPI-tables-via-DT friend I think.
<ardb>
yep
<ardb>
which likely means they have decided to use EFI boot after all
<palmer>
OK, so maybe they've got something weird going on?
<palmer>
does this actually manifest upstream somewhere?
<ardb>
does what manifest?
hightower3 has joined #riscv
<palmer>
the GP trashing -- I took that `Compared with gcc version 12, gcc version 13 uses the gp register for compilation optimization, but the efistub module does not initialize gp.` to mean something's broken
<xypron>
U-Boot is compiled with -ffixed-gp. I can not see this in EDK II. EDK II further seems not to have code to restore gp after reentry. So I wonder if it is UEFI compliant in this respect.
hightower2 has quit [Ping timeout: 255 seconds]
<ardb>
palmer: we fixed that, those are the fixes that are being reverted
<sorear>
definitely, there shouldn't be any difference between gcc-12 and gcc-13 for gp usage
<ardb>
unless gcc-13 is ignoring the -mno-relax option?
<sorear>
-mno-relax doesn't matter because relaxations are applied by ld, not gcc
<sorear>
so the gcc version is irrelevant
<sorear>
gp is used for shadow stack but I think that's a clang-only feature?
<ardb>
but if the R_RISCV_RELAX relocations are not emitted, will ld still perform those relaxations?
<sorear>
gcc-12 generated the relocations, as does gas, it's not a new feature in gcc-13
<ardb>
shadow stack is disabled in the EFI stub, and we use -mno-relax and inspect the binary to ensure no R_RISCV_RELAX relocations are present
<ardb>
so i would assume the resulting code never touches GP unless it does so deliberately, e.g., via inline asm
<conchuod>
Would it surprise you if there were some stub "extensions" involved?
<conchuod>
From the kinda layman PoV when it comes to relocations etc, it seems like they disabled the things stopping the stub using GP and then added support for restoring it. That seems as if they want to actively use it /shrug
<sorear>
if by "binary" you mean anything other than an object file there won't be R_RISCV_RELAX, those are removed by linking...
<ardb>
by binary i mean the static ELF library that contains all the EFI stub code
<ardb>
depending on the architecture, this gets linked into either the core kernel, or the decompressor/preloader
<sorear>
Do we know how EFI_MP_SERVICES_PROTOCOL.WhoAmI is supposed to work on riscv?
clandmeter has quit [Quit: Ping timeout (120 seconds)]
clandmeter has joined #riscv
davidlt has quit [Ping timeout: 268 seconds]
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #riscv
BootLayer has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<jrtc27>
ardb: yeah so it's really just up to the UEFI spec to define what it wants to do with GP
<jrtc27>
probably a UEFI application should be like a normal application and be in control of GP
<jrtc27>
but then you have two non-library things in the same address space so it's a bit messy
Armand has joined #riscv
vagrantc has joined #riscv
davidlt has joined #riscv
davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
<ardb>
the problem is that multiple EFI apps may be active at the same time, i.e., the firmware calling GRUB calling the EFI stub
<ardb>
if GRUB is permitted to use GP, the EFI stub should at least restore it before exiting
<ardb>
but GRUB may register for event callbacks too, which may fire while the EFI stub is executing
<jrtc27>
sure
<ardb>
in summary, i don't think we should touch GP at all in EFI without proper guidance of how this sharing is supposed to be implemented
<heat>
protocols could possibly not work at all (as well) if anyone messes with gp
<jrtc27>
and IIRC all the Dxe .dlls etc are really applications too from the linker's perspective
<heat>
i guess gp really isn't usable at all in the whole of EFI, is it?
<ardb>
i guess not
<heat>
i don't know how ldso gets around the limitation of having one gp register, but EFI is essentially many programs that expose random function pointer tables you can call from anywhere
<jrtc27>
ldso is an so
<heat>
are .so's never allowed to use gp relaxation?
<jrtc27>
so implicitly the (static) linker knows to not use gp
<jrtc27>
correct
<jrtc27>
only the application
<heat>
ah, cool
<jrtc27>
the problem here is that everything is an application in UEFI land
crossdev has quit [Remote host closed the connection]
<jrtc27>
not really
<jrtc27>
UEFI doesn't do TLS
<jrtc27>
so TP is reserved and unused by the toolchain
<jrtc27>
GP is a problem because the toolchain *is* using it if you're not careful
<sorear>
not even internally? some of the runtime services can explicitly be used from multiple cores, and there's MpService?
<jrtc27>
hm
<jrtc27>
so there's no PE/COFF TLS ABI to use
<jrtc27>
but that doesn't mean there isn't something highly ad-hoc
<ardb>
sorear: runtime services are not reentrant
<ardb>
the OS is required to use some kind of mutex to ensure that only one call is active at a time
<sorear>
gp is a linker problem, not a compiler problem, R_RISCV_RELAX is a promise from the compiler to the linker that it doesn't care about length or mind rewrites and doesn't _per se_ have anything to do with gp use
<sorear>
ardb: and the runtime services will never have to find a per-hart interrupt controller IO region or something like that?
<ardb>
that seems unlikely to me
<ardb>
runtime services typically don't access hardware directly once it is under the control of the OS
<sorear>
if 48-bit pc-relative instructions ever get ratified, R_RISCV_RELAX would be the appropriate way to use them; -mno-relax means "don't rewrite instructions", not "don't use gp"
<sorear>
if you want to not use gp, don't define __global_pointer$ and/or have the linker know what environment it's linking for
crabbedhaloablut has quit []
<sorear>
ardb: is UEFI PI a real thing that people care about?
<ardb>
you mean the PI spec?
<sorear>
yes
<ardb>
Intel cares about it deeply but from the OS perspective it has no relevance
<ardb>
it is basically a spec that describes how to build firmware
<ardb>
everything the OS should be able to observe is covered by the UEFI spec
crabbedhaloablut has joined #riscv
<sorear>
i see
<ardb>
e.g, u-boot's EFI implementation is UEFI compliant but it does not implement PI at all
<sorear>
do you need it for pci option roms?
<heat>
no
<ardb>
unfortunately, Tianocore/EDK2 is the reference implementation for both specs, and it is hard to distinguish what is UEFI and what is PI
<heat>
there might be an asterisk somewhere but AFAIK pci option roms are just standard uefi model drivers in ROM format
<ardb>
i.e., they all use EFI_ prefixes for type names etc
<ardb>
heat: no you're right - that is completely covered by UEFI
Trifton has quit [Quit: Client exited]
armand_ has joined #riscv
<sorear>
still feels like the DXE Boot Services are theoretically something that UEFI applications can care about
Armand has quit [Ping timeout: 264 seconds]
<heat>
you can ask for them (like efistub does/did), but then you're no longer really a EFI app
<heat>
(at least if you explicitly need them and fail if they're not there)
<ardb>
sorear: the DXE services are not supposed to be used by EFI apps
armand__ has joined #riscv
<sorear>
a few references to reentrancy and MP safety in the main UEFI spec but neither term is defined
handsome_feng has quit [Quit: Connection closed for inactivity]
armand_ has quit [Ping timeout: 264 seconds]
<ardb>
there is a whole TPL priority scheme for callbacks and event handlers, but this is all in the context of a single CPU
<ardb>
SMP basically does not exist, and the MP services protocol is a crutch to dispatch a tiny piece of code on another CPU
<ardb>
this is used on some ARM systems to populate SMBIOS tables, for instance, retrieving info that is only accessible to each respective core itself
<sorear>
it can't be implemented here because tp isn't usable and there is no sbi_hart_id() or shartid register
<ardb>
good riddance
<ardb>
don't use that if you can avoid it
<jrtc27>
the lack of shartid in the architecture pains me somewhat...
Leopold has quit [Remote host closed the connection]
JanC has quit [Ping timeout: 264 seconds]
EchelonX has quit [Quit: Leaving]
JanC has joined #riscv
Leopold has joined #riscv
ntwk has joined #riscv
psydroid has left #riscv [No boundaries on the net!]
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
Armand has quit [Ping timeout: 264 seconds]
bestcharlemagne has quit [Remote host closed the connection]
frkazoid333 has quit [Read error: Connection reset by peer]
Armand has joined #riscv
frkazoid333 has joined #riscv
Armand has quit [Ping timeout: 272 seconds]
Armand has joined #riscv
<courmisch>
sorear: not sure what you mean by SAD. To me, that's the short for seasonal anxiety disorder, a very real problem when one lives 60 degrees of latitude from the equator
dzaima[m] has joined #riscv
<dzaima[m]>
sum of absolute differences
<courmisch>
okay that's a little bit of a problem for encoding, yes
<courmisch>
also that's why I was whining about lack of integer vabs instruction
<courmisch>
but IME, the biggest problem with RVV for video coding is lack of reg-reg transpose
<dzaima[m]>
yeah a bunch of things having to fall back to vrgather isn't particularly nice
<courmisch>
vrgather does not really work. Calculating the indices from vid.v is just too complicated
<courmisch>
unfortunately, spilling on the stack then segmented-load is potentially "faster" than gather
<dzaima[m]>
there's the option of computing the indices in some lazy scalar way and loading that
prabhakalad has quit [Ping timeout: 252 seconds]
<courmisch>
yeah then you only need to burn one GPR for the address of indices
prabhakalad has joined #riscv
<courmisch>
but still vrgather scales quadratic with VL, while segmented loads scale linear
<dzaima[m]>
yeah that's the big problem
BootLayer has quit [Quit: Leaving]
<sorear>
not all implementations of segmented loads are constant in VLEN and vrgather can be split, sometimes
<courmisch>
vrgather can be split to smaller chunks for e.g. vector reverse
<courmisch>
but not really for transposition
<sorear>
if you're doing transposition within a register, which is the only case that makes sense to compare with other architectures, LMUL=1
<sorear>
I don't have a good understanding of where you'd use this in a video codec though
<courmisch>
this is done a lot in video, to deal with rows vs columns in macroblocks
prabhakalad has quit [Ping timeout: 268 seconds]
<courmisch>
I think dav1d is going to hurt a lot because of this but unlord would know better than me
<sorear>
that doesn't really help me reach a _good_ understanding
<courmisch>
if you need to transpose a MB of 8x8 samples, you can't realistically do it with LMUL=1
<courmisch>
to be fair, Arm is not exactly good with this either. It has transpose, but you need to call it many times over
<sorear>
is this a case where you want to do horizontal operations and have a choice between transposing before and after, and using slides to line things up?
<dzaima[m]>
is there really anything that handles transposes well? it's just a complex operation in general, with each output register approximately depending on each input register
<courmisch>
x86 shuffles are insanely fast
<dzaima[m]>
except on microachitectures where they're not, same as RVV could be
<courmisch>
sorear: if you want the underlying reasoning, you'd better ask someone with actual codec design/standard experience, i.e. unlord, not me
<courmisch>
dzaima[m]: in theory, yes, but I do OSS that's supposed to run on any hardware, not embedded, at the moment
Leopold has quit [Remote host closed the connection]
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
<sorear>
if ffmpeg is slow on slow hardware, that doesn't sound like a bug
<sorear>
by "insanely fast shuffles on x86" do you mean anything fancier than vpshufb?
<courmisch>
pshuf things, not that I'd have any experience with x86
<sorear>
what, exactly, do you have experience with and like
<dzaima[m]>
vunpckhps/vunpcklps etc end up neatly working for transposing, but you still need like 16 of such to transpose 8 registers of 8xi32
<courmisch>
if you mean SIMD, I've done some ARMv6 and ARMv7, and ARMv9. I suppose I could get used to ARMv8 easily
<dzaima[m]>
plus ~8 vperm2f128/vinsertf128
<courmisch>
it's anyway hard to compare x86, because x86 just sucks at scalar
<courmisch>
the performance gains of SIMD optimisations over C code are typically much more favourable on x86 than ARM (or RISC-V)
<courmisch>
and by that, I mean, even in situation where we're "missing" instructions in NEON or RVV
<courmisch>
+not
<courmisch>
I suppose that's what you get for having so hard to decode ISA
Leopold has joined #riscv
<sorear>
other factors don't help
<courmisch>
I don't disagree, but I can't go back in time and tell Intel to make x86 RISC
mlw has quit [Ping timeout: 272 seconds]
<courmisch>
somebody would have to write the affected kernels in dav1d or FFmpeg and compare RVV with NEON on comparable hardware if we want more objective and substantial data
<sorear>
can you point me at an affected kernel?
<sorear>
can you point me at profiling results showing what % of CPU time is spent on which kernel on a defined workload on some architecture and platform?
<courmisch>
I've been avoiding any kernel that looked like it required transposition so far, and I've been avoiding encoding side stuff in general (because I think *somebody* should be paid to do them)
<courmisch>
I believe that unlord has some stuff on dav1d though
<sorear>
i'll take a look at one that you've avoided so far
<courmisch>
and I don't think ffmpeg has harness for breaking down benchmarks that way
<courmisch>
it's pretty much only measuring one single kernel at a time
<sorear>
the level of detail I'm asking for is roughly "the first page of perf report output"
<sorear>
on a real encode/decode/transcode job
<sorear>
as opposed to ffmpeg *internal* benchmarking
<courmisch>
doing that on the C code should be easy for anybody who's familiar with relevant tracing tools
<courmisch>
doing it on the optimised code is impossible as there is not really any remotely close to fully optimised decoder and encoder as of yet on RVV
<sorear>
I'm familiar with the relevant tracing tools but I haven't used ffmpeg in over a decade and don't have a media library to test it on
<courmisch>
I'm not familiar with ffmpeg command line tool either, TBH
<sorear>
doing it on riscv optimized code is a nice to have, but I'm looking for order of magnitude estimates of which steps are actually important and which steps are asymptotically negligible and I doubt fully optimized vs C will be more than 10x in most places, 100x ever
<courmisch>
and this may be a more relevant question for x264 or x265 than for FFmpeg
<courmisch>
video encoding is not exactly where FFmpeg shines
Leopold has quit [Ping timeout: 255 seconds]
armand_ has joined #riscv
junaid_ has quit [Remote host closed the connection]
Armand has quit [Ping timeout: 256 seconds]
maylay has quit [Quit: Pipe Terminated]
maylay has joined #riscv
armand_ has quit [Ping timeout: 260 seconds]
Leopold has joined #riscv
Armand has joined #riscv
Leopold has quit [Ping timeout: 240 seconds]
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #riscv
KREYREN has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 264 seconds]
KREYREN has joined #riscv
naoki has joined #riscv
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #riscv
Leopold has joined #riscv
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #riscv
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #riscv
MaxGanzLaptop2 has quit [Ping timeout: 260 seconds]