ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
jwerner has joined #armlinux
apritzel_ has quit [Ping timeout: 255 seconds]
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #armlinux
DubPirate562 has joined #armlinux
amitk has joined #armlinux
DubPirate562 has quit [Quit: Leaving]
hanetzer has quit [Ping timeout: 264 seconds]
hanetzer has joined #armlinux
heat has quit [Ping timeout: 268 seconds]
cbeznea has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 246 seconds]
CrashTestDummy2 has joined #armlinux
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
apritzel_ has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 272 seconds]
CrashTestDummy3 has quit [Ping timeout: 252 seconds]
CrashTestDummy2 has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
apritzel_ has quit [Ping timeout: 272 seconds]
CrashTestDummy has quit [Ping timeout: 252 seconds]
CrashTestDummy3 has joined #armlinux
lain6141 has joined #armlinux
CrashTestDummy has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 272 seconds]
CrashTestDummy3 has quit [Ping timeout: 272 seconds]
CrashTestDummy2 has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 246 seconds]
CrashTestDummy has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 246 seconds]
CrashTestDummy3 has quit [Ping timeout: 272 seconds]
CrashTestDummy has quit [Ping timeout: 246 seconds]
gclement has joined #armlinux
gclement has quit [Client Quit]
frieder has joined #armlinux
iivanov has joined #armlinux
gclement has joined #armlinux
Livio has joined #armlinux
atorgue__ has joined #armlinux
atorgue1 has quit [Read error: Connection reset by peer]
atorgue has quit [Read error: Connection reset by peer]
atorgue has joined #armlinux
atorgue1 has joined #armlinux
atorgue__ has quit [Read error: Connection reset by peer]
sszy has joined #armlinux
snuggeypart431 has joined #armlinux
snuggeypart431 has left #armlinux [#armlinux]
snuggeypart431 has joined #armlinux
<snuggeypart431>
hello
hanetzer has quit [Ping timeout: 252 seconds]
snuggeypart431 has left #armlinux [#armlinux]
hanetzer has joined #armlinux
headless has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #armlinux
nsaenz has joined #armlinux
rvalue- has joined #armlinux
rvalue has quit [Ping timeout: 264 seconds]
rvalue- is now known as rvalue
Livio has quit [Ping timeout: 256 seconds]
Livio has joined #armlinux
nsaenz_ has joined #armlinux
nsaenz has quit [Ping timeout: 264 seconds]
headless has quit [Quit: Konversation terminated!]
CrashTestDummy has joined #armlinux
CrashTestDummy2 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 256 seconds]
CrashTestDummy3 has joined #armlinux
apritzel has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 264 seconds]
CrashTestDummy3 has quit [Ping timeout: 256 seconds]
CrashTestDummy has joined #armlinux
CrashTestDummy has quit [Ping timeout: 252 seconds]
nsaenz_ has quit [Ping timeout: 256 seconds]
nsaenz has joined #armlinux
kwizart has joined #armlinux
luispm has quit [Ping timeout: 264 seconds]
<kwizart>
Hello armlinux. I need some advice about older armhfp board for a mesa bug (with llvmpipe). Basically newer llvm has reversed the cpu feature logic so this need to be re-sorted
<kwizart>
basically as soon as the CPU lacks neon, there are also others features that cannot be assumed. Best would be to have theses feature properly conditionalized
<robmur01>
kwizart: Seems like that's an issue between Mesa and LLVM? If you're already able to detect the HWCAPS for the features that *are* present, then it's just a case of explicitly configuring the compiler to use those and only those
<robmur01>
if you want to be portable, don't make any assumptions about how the distro/user/whoever may have configured a particular compiler's defaults
<militantorc>
how do you do portable then? explicitly set all flags of gcc?
<militantorc>
*whatever compile
<militantorc>
*whatever compiler
<robmur01>
all the ones relevant to the ISA and instruction/register selection, yes
<robmur01>
you don't know if, say, "arm-none-eabi-gcc" alone is going to generate code for ARM926 or Cortex-A72
<kwizart>
robmur01, thanks. right I'm currently trying to see if all features can be detected... so this would give something like this (no compile test/ desc update yet): https://paste.centos.org/view/4a125f10
<kwizart>
I'm assuming -crypto is an aarch64 thing, so not relevant in #if DETECT_ARCH_ARM case
<robmur01>
no, crypto exists in v8 AArch32 as well
<robmur01>
(to an extent, at least)
<kwizart>
Okay, so it means it works for me because my host triplet doesn't assumes crypto ?
<kwizart>
(i'm doing native compilation on fedora, but I should meant target triplet)
dmart has joined #armlinux
<robmur01>
well, it should really depend on NEON anyway. Plus I doubt llvmpipe does much that could use AES or SHA instructions in the first place :)
<kwizart>
right
<kwizart>
robmur01, there is already such mention for x86 like "buggy setup" qemu that would only expose crypto but not neon altough real arm CPU would never have such case.
<kwizart>
not sure if there is a need to handle such case
<arnd>
kwizart: I think it's reasonable to assume that the kernel correctly identifies the available features. If this is broken in qemu, it should be fixed in qemu, not in gallium
<robmur01>
I mean in the compiler as well - if you tell it not to use NEON then logically it cannot use crypto instructions which operate on NEON registers either
<arnd>
From what I see on the other architectures, you should have a line per feature like "MAttrs.push_back(util_get_cpu_caps()->has_neon ? "+neon" : "-neon");" to enable or disable it based on the CPU alone, with no check for preprocessor macros
<kwizart>
arnd, sure. llvm/mesa "used not to" do much runtime detection beyound neon. Others features are likely to be assumed at build time (given the -march=armv7-a)
<kwizart>
I think my bug was just that, fedora build with -march=armv7-a -fpu=vfp3-d16 but llvm would assumes vfp32 at runtime.
<arnd>
kwizart: you have a corner case where mesa is built for ARMv5 softfloat, but you are running on an ARMv8/aarch32 with NEON, so you want llvmpipe to use the NEON instructions
<robmur01>
Looks like Mesa's check_os_arm_support() could stand to be fleshed out for HWCAP_VFPD32 etc. as well
<arnd>
same as how i386 binaries running on modern x86-64 hardware enable avx2
<kwizart>
OK, so instead of pre-processors checks, the best way forward is runtime checks, even for arm
<arnd>
yes
<arnd>
the various options for FPU features make this is little complex, but it's still nor as bad as x86