On Sun, 2 Oct 2016 02:25:30 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Sun, Oct 02, 2016 at 01:18:29AM +0200, Henrik Gramner wrote: > > Ensuring that emms is issued before every single libc function call is > > likely problematic. > > maybe, maybe not, iam not sure but > calling emms between init/de/reinint and optimized inner loops should > be doable, we generally shouldnt be doing malloc in highly optimized > loops as factorizing allocation out and reusing buffers is likely > a better choice +1 for not leaving the C environment and the FPU in a broken state. > beyond malloc() what else is there ? > > string functions ? > these are in fact not unlikely to use SIMD of some sort > same for memcpy/move() > > also there are callbacks like av_log() we should document any > requirements that apply to them or ensure no such requirements exist > > exact backtraces of where issues occur would be interesting to better > understand how much code is affected by this > > > > > > What if we simply document the requirement that C standard library > > functions are assumed to not modify the x87 FPU state unless > > specifically designated to handle floating-point numbers? > > thats like saying that we require undefined behavior to be defined > in a specific way. We can do this but thats like saying we support > only a subset of POSIX platforms and that subset could shrink at > any time if implementations change > > I think our first choice should be to comply to specs where its > needed in practice and doable. > when its not useful in practice and a total unreadable mess if done > i would tend suggest to ignore specs. > > If all else fails we could add a emms call behind #if in > av_malloc() and detect affected libcs but thats IMHO a ugly hack > but better than declaring "non support" > Yes, that would be a very ugly hack that should be avoided. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel