[Ffmpeg-devel-irc] ffmpeg-devel.log.20140516

[burek]

[00:08] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:bebce653e560: avcodec/x86/dsputil_mmx: Fix build with clang-usan
[00:44] <cone-725> ffmpeg.git 03Carl Eugen Hoyos 07master:30aeab29e468: Use av_restrict instead of restrict in libavcodec/opus_celt.c.
[03:19] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:a071c0b515e5: avcodec/utils: Fix undefined behavior in avpriv_toupper4
[03:19] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:1fb46858c249: avcodec/cavs: prevent out of array read
[05:23] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:7970959a9412: avcodec/opusdec: fix some const correctness
[05:43] <cone-725> ffmpeg.git 03James Almer 07master:cdff1cc98f3b: configure: add check for AVX inline support
[05:43] <cone-725> ffmpeg.git 03James Almer 07master:a9bf713d350a: swresample: add swri_resample_float_avx
[06:58] <cone-725> ffmpeg.git 03Masa Utashiro 07master:491d602283cd: avfilter/vignette: fix input frame memory leak.
[07:13] <cone-725> ffmpeg.git 03Clément BSsch 07master:8a0ba44e1ac1: vignette: reuse already declared ctx.
[07:13] <cone-725> ffmpeg.git 03Clément BSsch 07master:ed7bc5471b63: avfilter/vignette: add direct rendering.
[07:13] <cone-725> ffmpeg.git 03Clément BSsch 07master:bac08cf086bb: avfilter/vignette: reindent after previous commit.
[13:44] <BBB> really, inline avx?
[13:44] <BBB> ;(
[13:44] <BBB> I mean
[13:44] <BBB> I'm going to cry
[13:44] <BBB> can we please not do that
[13:45] <nevcairiel> its too late
[13:49] <BBB> let's throw a hassle on the ML
[13:50] <nevcairiel> for the sse case of the same function it was apparently slower to do it in yasm
[14:02] <plepere> BBB, nevcairiel I've submitted the DBF patch
[14:02] <BBB> I noticed, I didn't look at it yet but I saw the earlier and it mostly looked ok
[14:03] <BBB> there's some odd stuff in there (like calling beta/tsc no_q and q or so)
[14:03] <BBB> but these are minor documentation things rather than anything else
[14:03] <BBB> plepere: one thing that would be nice is if you could make register usage more contrained
[14:03] <BBB> you're very quickly going from 6 to 15 registers from chroma to luma
[14:03] <BBB> I'm not sure you need that many
[14:03] <BBB> (GPRs, not XMMs)
[14:04] <plepere> it's not my code, but ok. :p
[14:04] <BBB> plepere: also, using named registers would be very cool (global function_name, n_args, n_gprs, n_xmms, arg1, arg2, arg3, arg4
[14:04] <plepere> I was hoping to get on the idct if this patch was accepted.
[14:04] <BBB> so you can do [arg1q]
[14:04] <BBB> I'm ok with it for now, mark them as FIXMEs so we can get back to them later
[14:04] <plepere> BBB : I'm using that already
[14:05] <BBB> you're using a lot of r1d, r1, etc.
[14:05] <plepere> ah only in luma maybe
[14:05] <plepere> ok ok, I'll do that.
[14:05] <BBB> 15 gprs is also a little much, I don't think you use all 15 in practice
[14:05] <BBB> it's minor, mark as FIXME to fix later
[14:05] <BBB> but do mark it as FIXME because it's kinda silly
[14:06] <plepere> I'll do that now
[14:06] <BBB> t
[14:06] <BBB> oops
[14:06] <BBB> ty
[14:06] <plepere> by the way, is there an easy way to check if a function has only SSE2 or SSSE3 instructions ?
[14:07] <plepere> except checking each instruction
[14:07] <BBB> you can run under qemu
[14:07] <BBB> but that's kinda a lot of work
[14:07] <BBB> so I don't know of an easy way
[14:07] <plepere> ok, thanks anyways
[14:07] <BBB> I typically just mark it as what I think it is or what the goal was for it to be
[14:08] <BBB> if it's wrong, people will file bugs
[14:08] <plepere> ok, I'll leave as it is then.
[14:09] <plepere> I'm doing the named registers, try to limit the number of register usage in luma and then I'll work on the idct
[14:09] <BBB> yay
[14:09] <BBB> ty
[14:09] <plepere> and then I'll be able to work on AVX2. That's what I'm looking forward to.
[14:12] <kurosu> some perl wizardry might be able to catch most cases by checking forbidden insn
[14:12] <kurosu> though there's the issue of insn forbidden with particular operands (like movd)
[14:13] <kurosu> might also need to operate on the postprocessed or disassembled code
[14:14] <plepere> kurosu, I'm working on assembly, so I could have a list of blacklisted instructions. that's a nice idea
[14:17] <kurosu> I don't have a list, but your luma deblock code looked like it was ok once you had macro'ed pabsw
[14:17] <kurosu> http://en.wikipedia.org/wiki/SSSE3#New_Instructions <- integer insn introduced by SSSE3
[14:17] <plepere> kurosu, maybe, but since I'm not sure, I prefer leaving this as it is.:
[14:19] <kurosu> http://ref.x86asm.net/coder64.html <- a lot of info, among which the required info
[14:20] <kurosu> nevermind, it lacks some ssse3 insn
[14:21] <kurosu> http://ref.x86asm.net/coder.html <- better
[14:23] <plepere> great, bookmarked.
[14:23] <plepere> :)
[14:23] <plepere> thanks
[14:27] <plepere> BBB : you were right : I could even squeeze the chroma from 6 registers to 5. :p
[14:27] <kurosu> plepere, although I guess you do sometimes, my suggestion is to look at the disassembled code for code with lots of macros
[14:28] <kurosu> it's easy to miss obvious things, like m6 and m8 being used but not m7
[14:29] <plepere> I tend to look at pre-processor code rather than the disassembled one
[14:36] Action: Skyler_ peeks in and sees asm
[15:52] <Voicu> whoever designed the java API must have been drunk and/or high
[15:52] <Voicu> there is no way a sane person would unleash something like that on a fellow programmer
[23:39] <michaelni> what happened with cone ?
[00:00] --- Sat May 17 2014