similar to: MMX and extended-MMX acceleration patch for encoding

Hi people, As I said before: I did the IDCT to run on the FPGA. My friends from university did the Reconstruction routines running on the FPGA. I'm helping with the LoopFilter, and it is almost there. (all VHDL) I did a small profiling of the libTheora running on a Altera Stratix II device: The processor used was the NIOS II with 8Kb of data and instruction cache, branch prediction and

Hello, just by curiosity, what is the current development status of theora? (TODOs, etc.) Only the documentation still left out? :-) Rodolphe --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body.

Hi all, I am trying to build the mmx version of the theora and the encoderwin is throwing the following errors. 1>------ Build started: Project: encoderwin, Configuration: Debug Win32 ------ 1>Linking... 1> Creating library encoderwin.lib and object encoderwin.exp 1>LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library

Hello, apparently, the following one-liner patch to automake file "lib/Makefile.am" is needed to build theora in a separate build directory. This may be convenient to build several versions of the library based on the same source tree, or just to keep the source tree clean. Note too that -I. is not needed, automake does an implicit -I$(srcdir) IIRC. <p>Rodolphe

I recently diagnosed a bug in someone else's software, which turned out to be due to incorrect MMX intrinsics usage: if you use any of the x86 intrinsics that accept or return __m64 values, then you, the *programmer* are required to call _mm_empty() before using any x87 floating point instructions or leaving the function. I was aware that this was required at the assembly-level, but not that

On Mon, Aug 31, 2020 at 3:02 PM Eli Friedman <efriedma at quicinc.com> wrote: > Broadly speaking, I see two problems with implicitly enabling MMX > emulation on a target that has SSE2: > > > > 1. The interaction with inline asm. Inline asm can still have MMX > operands/results/clobbers, and can still put the processor in MMX mode. If > code is mixing MMX

Please include a testcase with the patch. gas uses " nopl 0x0(%eax)" for k6_2. Are you sure it is a gas bug? On 3 November 2013 13:50, Mikulas Patocka <mikulas at artax.karlin.mff.cuni.cz> wrote: > Hi > > This patch fixes code generation bug - 586-class CPUs don't support the > nopl instruction and some 686-class CPUs don't support it too. > > I

Hi This patch fixes code generation bug - 586-class CPUs don't support the nopl instruction and some 686-class CPUs don't support it too. I created bug 17792 for that. BTW. I think you should also optimize padding on these CPUs - instead of a stream of 0x90 nops, you should generate variants of "lea (%esi), %esi" instruction like gcc. This patch disables generation of

On Tue, 5 Nov 2013, Rafael Espíndola wrote: > Please include a testcase with the patch. I'm sending testcase here. Compile it with "clang -O2 -march=k6-2 -c loop.c" > gas uses " nopl 0x0(%eax)" for k6_2. Are you sure it is a gas bug? Yes, it is gas bug. I should report it to binutils maintainers. Mikulas > On 3 November 2013 13:50, Mikulas Patocka >

Hello, I would like to announce the semi-optimized oc_state_loop_filter_frag_rows It gains like 7% speedup. Unfortunately it has some issues: 1) wont compile on 64bit (I will fix it later hopefully) 2) is not yet fully optimized (instruction stalls) Here are the results. CPU: Athlon, speed 1466.91 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask

From: alex at milivojevic.org > At various points in time Red Hat made some somewhat conflicting > decisions. The first was that Red Hat distributions must have NPTL. > For NPTL support, there are two components of system where it is > implemented, kernel and glibc. Back then glibc supported NPTL only > for i686. NPTL support was later backported to i586 and i486. Also remember

Hi there. This patch changes the block selection to quantify error based on the sum of the squared differences of the pixel values rather than the sum of the absolute differences, the former conventionally and statistically seeming like the preferable thing to do. The patch also const'ifies some parameters (which doesn't affect code quality on recent GCCs but might help on older/ other

Along with libtheora-1.0alpha5 this is a release of theora-mmx. A drop in replacement that uses MMX assembly to speedup some of the most demanding routines in theora encoding/decoding. Right now it only works on 32bit x86 CPUs. Thanks to everyone whose work made this release possible! Download links: http://downloads.xiph.org/releases/theora/libtheora-mmx-1.0alpha5.tar.bz2

Hi Nicolas, > I found out that the performance regression is due to removing support > for lowering 64-bit vector operations to MMX, and using SSE2 instead. My > code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs > back and forth between MMX and SSE2 instructions in the generated code. > > To get more optimal code, I see three options, and I was wondering

On Sep 8, 2010, at 7:24 AM, Eli Friedman wrote: > On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens > <nicolas.capens at gmail.com> wrote: >> Hi Chris, >> >> It's not broken, but the performance is crippled. >> >> I noticed that the code still contains some MMX instructions, but several >> operations get expanded (apparently swizzling and such

While I know that, technically, the only i586 machines are the Pentium and Pentium MMX, it is still nice that I can use some headless AMD K6/2 machines I have lying around for CentOS 4. Many thanks for the effort expended to get that working. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu

Might you instead consider just adding a -disable-mmx option? Preston On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: > Hi, > > When setting -mattr option on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get

On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > Hi, > > When setting -mattr option on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while > llc -march=x86 -mattr=mmx

Hi Dale, I will not change the default. I would dislike to see any regressions due to this type of change. -- Mon Ping On Nov 20, 2008, at 10:12 AM, Dale Johannesen wrote: > > On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > >> Hi, >> >> When setting -mattr option on X86, I would like to treat MMX >> separately from SSE levels. This would allow a

On Nov 20, 2008, at 8:31 AM, Preston Gurd wrote: > Might you instead consider just adding a -disable-mmx option? I agree, this is a better approach. This distinguishes between capabilities of the chip and the desire to codegen specific vectors one way or another. -Chris > > Preston > > On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: >> Hi, >> >>