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 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" -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel