similar to: bitpack.c odditiy

Hi folks. Mozilla had some issues with the MMX optimized frag_recon functions over the last days, and I was able to track the problem down. The code itself is fine, but it unfortunately it has the tendency to cause a non-deterministic compiler bug. The whole discussion is here: https://bugzilla.mozilla.org/show_bug.cgi?id=474937 After thinking about the problem I've suggested to

Hi folks, FYI: I've finally made some benchmarks for inline-assembler versus intrinsic based mmx code. I've just applied the changes to the fragment reconstruction functions as writing the IDCT and loopfilter have not been ported yet. Nevertheless here are some numbers: As a baseline I'll take the current version from the trunk with all inline assembler functions enabled. Lower

Here is the patch with my changes. Most work went into the decoder. I just changed on the encoder if something was nessesary to build the library. You can find the patch here (quite big).. http://torus.untergrund.net/code/theora_mmx_vc2005.diff Please let me know if the encoder works without problems. I just did a very brief testing of it. The decoder has been tested against the test

Hi, i have some code that gives me a "warning: Buffer too small to pack bits" mesage. looking at the libspeex source/bits.c i see the warning in a a function named speex_bits_pack. i'm not using this function. can someone tell me where this may be coming from since i've had a similiar problem before and had that fixed. i can't seem to pinpoint this one. thanks Greg

Hi there. I try to cross-compile the theora libraries to test my ARMv6 optimizations (almost done, time to do some benchmarking and testing). While doing so I found out that --with-ogg seems to do nothing. If I simply run: .configure --with-ogg=$HOME The build succeeds also it shouldn't (I don't have ogg installed at $HOME). As an example here is the last line that make executes.

i don't think so. this is my current code: for(i=0; i<samples;i++){ /*only get max 320 bytes at a time so bits can handle*/ Client->raw_audio[i] = *input++; Client->temp_audio[i] = Client->raw_audio[i]; Client->session_File[ndx] = Client->temp_audio[i]; ndx+=1; } speex_bits_reset(&ebits);

Hi again, I measured my fragment reconstructions against the compiler output from GCC and well - the new codes perform better, so I brushed up my gcc inline assembler skills and made a port. Code is here: http://torus.untergrund.net/code/mmxfrag.c All routines perform much better now. Inter2 alone got a speedup of factor 5 on Pentium-M. Athlon CPU's execute roughly 3 times faster.

Hi, As a first step to port the LLVM chain on an in-house big-endian processor, I'm integrating the native assembler as a new '-assemble -arch=' in llvm-mc. All work quite well, I have a correct output ELF format except that generated code is little-endian. I've understood that the endianess of the LLVM chain is controlled by the DataLayout class, but it appear to me that llvm-mc

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions use big endian order? Is it safe to mix calls to

From googling around, it seems that the ogg bitpacker has defined endianness, but I can't find anywhere that says which order it's in. Any help? The endianness of the 24 bit field in the OggPCM header should be specified. I was going to edit the wiki to specify it as network byte order, then realized that you may have standardized on something else in theora/vorbis already.

With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") --- .../gpu/drm/nouveau/nvkm/engine/device/base.c | 39 ++++++++++++------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c

I have undertaken a small project of writing a Vorbis decoder completely from the spec, with the goal of catching any errors, both typographically and algorithmically, in the spec. My "reference" decoder is also being written in an extremely methodical style, with practically no algorithmic optimization, such that it will be clear that every step has been copied exactly from the spec.

On Mon, 2014-09-08 at 22:00 -0400, Samuel F Antao wrote: > Alexey, Alexander, > > Thanks for the suggestions. I tried removing the flag SA_NODEFER but > it didn't do any good... I have been digging into the problem with the > null_deref test today but I was unable to clearly identify the > problem. I suspect that it was either a bug with the calling > convention/unwinding

> + vpmem->vdev = vdev; > + vdev->priv = vpmem; > + err = init_vq(vpmem); > + if (err) { > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n"); > + goto out_err; > + } > + > + virtio_cread(vpmem->vdev, struct virtio_pmem_config, > + start, &vpmem->start); > + virtio_cread(vpmem->vdev, struct

> + vpmem->vdev = vdev; > + vdev->priv = vpmem; > + err = init_vq(vpmem); > + if (err) { > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n"); > + goto out_err; > + } > + > + virtio_cread(vpmem->vdev, struct virtio_pmem_config, > + start, &vpmem->start); > + virtio_cread(vpmem->vdev, struct

A couple of questions: * Do I need a named account to commit changes? How do I get such an account? I'm used to commit roughly once every 8 hours of work if I have a stable point that compiles on linux and win32. That's just my way of working. Worked well in the past to protect myself from doing stupid things. * How anal are you about line endings, tabs vs. spaces, max. line length

On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > The problem I've had is building an LLVM cross-compiler from Linux/ > x86 to Linux/ARM (as has another llvm-dev poster). Someone > mentioned to me off-list that he managed to get it to build, but I > haven't been able to reproduce the build using his instructions > (I'll post my results in another thread).

On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at complang.tuwien.ac.at>wrote: > On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > > The problem I've had is building an LLVM cross-compiler from Linux/ > > x86 to Linux/ARM (as has another llvm-dev poster). Someone > > mentioned to me off-list that he managed to get it to build, but I > > haven't

One possibility is that Lame is using the wrong endianess for your system try changing NUMBER_LITTLE_ENDIAN to NUMBER_BIG_ENDIAN in liveice.h and rebuilding. The default distribution of Lame uses big endia samples on IO, which means that in raw input mode it needs the -x arg to be set. However - some 'helpful' people have made this the default on some distributions.... so when liveice

> hton and ntoh intrinsics. These are needed to allow target code to > deal with endianness in a target independent way. (Ok, you could > potentially write code that detected endiannes at runtime and chose > multiversioned code based on that, but that is ugly and optimization > prohibiting). > Why not add types with explicit endianess? A trick I use for reading binary files