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
tiagom has quit [Ping timeout: 246 seconds]
tiagom has joined #armlinux
nact has joined #armlinux
heat has quit [Ping timeout: 246 seconds]
jclsn has quit [Ping timeout: 248 seconds]
tiagom has quit [Ping timeout: 246 seconds]
jclsn has joined #armlinux
mriesch has quit [Remote host closed the connection]
mriesch has joined #armlinux
SystemError has quit [Remote host closed the connection]
nsaenz has quit [Read error: Connection reset by peer]
HerbY_NL has joined #armlinux
nsaenz_ has joined #armlinux
nsaenz_ has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
siak has joined #armlinux
rvalue- has joined #armlinux
rvalue has quit [Ping timeout: 255 seconds]
rvalue- is now known as rvalue
psydroid has quit [Read error: Connection reset by peer]
headless has joined #armlinux
HerbY_NL_ has joined #armlinux
HerbY_NL has quit [Ping timeout: 248 seconds]
fvincenzo has joined #armlinux
psydroid has joined #armlinux
heat has joined #armlinux
gclement has quit [Ping timeout: 252 seconds]
fvincenzo has quit [Quit: leaving]
gclement has joined #armlinux
HerbY_NL has joined #armlinux
HerbY_NL_ has quit [Ping timeout: 244 seconds]
headless has quit [Quit: Konversation terminated!]
SystemError has joined #armlinux
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
luispm has quit [Remote host closed the connection]
Saalim has quit [Remote host closed the connection]
Saalim has joined #armlinux
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
<ardb>
arnd: DC ZVA is the tricky one: memset() will use that for zeroing memory, but it is simply never allowed on device mappings
<ardb>
that is why, e.g., the nouveau DRM userland did not work on synquacer for mpeg decoding
<ardb>
but to the userland abstractions in question, all the memory they operate on is just memory, they don't track whether it is backed by system RAM or something else at the kernel level
Saalim has quit [Ping timeout: 252 seconds]
Saalim has joined #armlinux
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
luispm has joined #armlinux
fvincenzo has quit [Quit: leaving]
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
geertu has quit [Read error: Connection reset by peer]
geertu has joined #armlinux
fvincenzo has quit [Quit: leaving]
fvincenzo has joined #armlinux
iivanov_ has joined #armlinux
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
iivanov has quit [Ping timeout: 260 seconds]
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
mvaittin has quit [Ping timeout: 252 seconds]
HerbY_NL has joined #armlinux
atorgue has joined #armlinux
sudeepholla_ has quit [Ping timeout: 248 seconds]
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<arnd>
ardb: what I meant is to always use custom string functions on CPUs with broken PCI, like we do for the optimized string functions on Qualcomm CPUs except these would completely avoid all the clever bits that don't work on device memory. Or does gcc produce DC ZVA even for an inline memset it generates on a struct initialization?
<ardb>
arnd: it would surprise me if GCC did that. if replacing/rebuilding userspace is in scope, building with -mstrict-align seems appropriate (in which case the string routines hopefully DTRT as well)
<arnd>
makes sense, but I don't think ajb-linaro would consider rebuilding all of userspace. Adding a CPU specific special case into glibc string functions is probably already a bit much, at least if the idea is to upstream that
mrkajetanp has joined #armlinux
<ardb>
arnd: if your GPU memory does not behave as normal memory, things will keep breaking all over the place, i suspect
<arnd>
ardb I'm not sure about that, since there is only a limited set of things that are done on it, and most of the time it seems to come down to memset() or memcpy(). The thing is that any unaligned access is likely already slow on normal x86, and completely broken on armv5 or mips
fvincenzo has quit [Quit: leaving]
fvincenzo has joined #armlinux
<arnd>
ardb: An important counterargument of course is that uncached access to PCI VRAM is so awfully slow that using a vulkan driver on top of it is unlikely to actually be any good.
<ardb>
arnd: i guess that is a variation of 'does not behave as normal memory'
<arnd>
I wonder what they were expecting users to plug into those three PCIe x16 slots in the first place, if GPU is not one of the options
<arnd>
Or why the hardware can claim to support "Arm SystemReady SR V2.1" compatibility if it has no working PCIe
<arnd>
(actually, I guess I know the answer to the second one)
<broonie>
arnd: Network cards?
<broonie>
or storage I guess.
fvincenzo has quit [Quit: leaving]
fvincenzo has joined #armlinux
<arnd>
Sure, but you can only have so many of those, and it already comes with 4x 10gbe ports
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #armlinux
<ardb>
arnd: does it say the PCIe has to work correctly?
<arnd>
it's the same thing as the Apple Mac Pro, which I think comes with seven slots and can't use GPUs for almost the same reason. At least they have a display controller on chip
<ardb>
arnd: if there is validation code, it probably doesn't scrape the frame buffer and check the picture for correctness
<ardb>
(if that is even possible in a generic manner)