michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
mkver has quit [Ping timeout: 268 seconds]
IndecisiveTurtle has quit [Ping timeout: 272 seconds]
cone-356 has quit [Quit: transmission timeout]
rossy has quit [Remote host closed the connection]
rossy has joined #ffmpeg-devel
\\Mr_C\\ has quit [Remote host closed the connection]
<courmisch>
hmm, should the Zvbb stuff go in ..._rvv.S or ..._rvbb.S or what?
<courmisch>
_rvvbb.S ?
<jamrial>
BBB: at least in my tests, for a single byte splat pshufb is not better than sse2 emulation, and slower than an avx2 broadcast
<jamrial>
courmisch: _rvbb.S imo
<BBB>
avx2 broadcast is better, yes. sse2 emu using punpcklbw+wd+pshufd? I'd assume pshufb to be faster but who knows :) courmisch has a point, everyone has avx2 these days so meh
<jamrial>
BBB: for a single byte splat done before a loop, i guess the memory load penalty for pshufb is higher than three unpack instructions
<BBB>
memory load?
<courmisch>
oh but there is also Zvkb, "a proper subset of the Zvbb extension. Zvkb allows for
<courmisch>
vector crypto implementations without incuring the the cost of implementing the
<courmisch>
additional bitmanip instructions in the Zvbb extension"
<courmisch>
RISC-V specs will single-handledly increase the relative frequency of Z in English
<BBB>
jamrial: movd x, [mem]; pxor y, y; pshufb x, y vs. movd x, [mem]; punpcklbw+wd x, x; pshufd x, x, 0
<BBB>
jamrial: right?
Krowl has quit [Read error: Connection reset by peer]
<jamrial>
BBB: no, gpr value, so no memory
<jamrial>
but you're right, pxor y, y might make a difference. what i did was load pb_0 for pshufb
<BBB>
:)
<BBB>
we use that in other places, and from memory that is faster (although only barely) than punpcklbw+wd+pshufd
<BBB>
but I agree it's all silly and avx2 is the wy to go
mkver has quit [Ping timeout: 272 seconds]
<courmisch>
the year is 2024 and people still write code with only 16 GPRs
mkver has joined #ffmpeg-devel
<courmisch>
Intel APX anyday now
<BBB>
needing more than 16 is honestly quite rare... vector registers, sure, more is betterder
<BBB>
I suppose for film grain synthesis more would've been nicer, that algo is quite complex
<courmisch>
wut? try compiling anything with LTO
Sean_McG has joined #ffmpeg-devel
Coinflipper has quit [Quit: ]
Coinflipper has joined #ffmpeg-devel
<Lynne>
I've never had to resort to any of the tricks I used to do for 32-bit systems on 16gprs
<Lynne>
a few more gprs would have made the intra-asm ABI of lavu/tx slightly nicer, but it wasn't too bad
muiz has joined #ffmpeg-devel
muiz_ has quit [Ping timeout: 268 seconds]
<Gramner>
more gprs from apx should be great for compiler-generated scalar code. for simd it would rarely matter, althought it might reduce prologue/epilogue code a bit if they're volatile
<courmisch>
APX is only for JITs. x86 will be obsolete before APX is universally available and can be relied on in compiled native code
<Lynne>
meh, I'm sure amd will do it for zen 6
<Lynne>
distros will not spin off all their packages for it though, no way
Krowl has joined #ffmpeg-devel
<courmisch>
Lynne: but that's the point. It'll *never* be enabled im non-embedded code
<Lynne>
I think if it was packaged into the same extension proposal which removed the 32-bit part, it could have had a chance
<courmisch>
20 years after Debian RISC-V enables Zba by default
<courmisch>
long after we are retired (if even alive)
<Lynne>
yeah, that situation is really bad, those instructions should have been part of baseline, or at least present in the first wave
<Lynne>
retirement? lol
<courmisch>
yes, retirement. the thing 5 days before you die
<Lynne>
ah, the government must have bumped the limit up
<Lynne>
wait, how do they know when you'll die so the limit is 5 days before?
<another|>
*X-Files theme plays*
<Lynne>
do they send ninja assassins armed with poison darts out each night to do it?
<Lynne>
if so, are they hiring?
<another|>
Nobody's alive to tell...
<Lynne>
even if they were alive, you wouldn't be able to tell, ninjas obey the laws of quantum mechanics
System_Error has quit [Remote host closed the connection]
<courmisch>
Lynne: they just let you retire when you are terminally ill
System_Error has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
darkapex has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<frankplow>
mkver: How are you finding all those missing dependencies? I presume for internal dependencies you can --disable-everything then have a script which enables individual components and tries compiling one-by-one but does this extend to third-party dependencies?
<mkver>
I only did it for our native stuff.
TheSashmo has quit [Quit: Leaving...]
___nick___ has quit [Ping timeout: 255 seconds]
TheSashmo has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 272 seconds]
cone-475 has joined #ffmpeg-devel
<cone-475>
ffmpeg Marton Balint master:8d92f59d117a: avformat/file: fail for non-numerical arguments to pipe:
<cone-475>
ffmpeg Andreas Rheinhardt master:aebddfd4d679: configure: Add missing dirac_decoder->qpeldsp dependency