search for: 16x16

AUTHORS | 1 + configure.ac | 1 + data/icons/16x16/Makefile.am | 2 ++ data/icons/16x16/swfdec.png |binary data/icons/22x22/swfdec.png |binary data/icons/Makefile.am | 2 +- 6 files changed, 5 insertions(+), 1 deletion(-) New commits: commit d6d82c2ed0e54d070fd0fd2bca41829aed370f4f Author: Benjamin Otte <otte at gnome.org> Da...

I''m looking for best practice for creating a hyperlink which has both an icon and text. I am currently using this in my view: <%= link_to image_tag(''icons/add.png'', { :align => ''absmiddle'', :border => 0, :size => ''16x16'', :alt => ''New education record'', :title => ''New education record'' }), new_education_path(@consultant) %>&nbsp;<%= link_to ''New education record'', new_education_path(@consultant) %> ... but it feels really really unD...

data/icons/16x16/Makefile.am | 3 +++ data/icons/22x22/Makefile.am | 3 +++ data/icons/24x24/Makefile.am | 3 +++ data/icons/32x32/Makefile.am | 3 +++ data/icons/48x48/Makefile.am | 3 +++ data/icons/scalable/Makefile.am | 3 +++ 6 files changed, 18 insertions(+) New commits: comm...

Yes those instructions exist, although they're a bit slower than the basic 16x16->32 with 32-bit accumulation (SMLABB). So I'd be surprised if the function with 64 bit accumulation would run as fast as the current code. Don't know how much we care about 16-bit platforms. And accuracy should not matter. On the other hand, a 64-bit implementation is much cleaner/sho...

Hi All, I'm a Speex newbie wanting to figure if it's worth trying to get the fixed point decoder working on an M32C processor. It has a hardware 16x16->32 multiply and a 16x16+48->48 multiply/accumulate in about 8 cycles and runs at 25Mhz. No shortage of RAM. I'm confident that I could make it work and am willing to commit the effort, but before I do so I should ask: 1) Does anyone know of a port to this or the M16C series of processo...

...kward for a cpu with a fused multiply-accumute unit? >From what I understand from responses to my older postings, Tremor's mdct_backward could be rewritten to take advantage of a muladd. My target machine can do either two-wide 32x32 + Accum(64) -> Accum(64) integer muladd or eight-wide 16x16 + Accum(32) -> Accum(32) integer muladd or four-wide single-precision floating-point muladd. The tremor code seems to be much cleaner and more portable than the stock version for consoles (no double-precision math routines, compiles more or less out-of-the-box on a C++ compiler) but I can affor...

...to the line above. I made ONLY this change to the 1.1.8 base that I am working from, and the problem is gone. I will go back to using fixed_generic.h for now, but it may still be worthwhile to make a custom version that takes advantage of the compiler intrinsics, which include 32-bit shifts, 16x16=32 and 32x16=32 MPY, and 32+16x16=32 MAC (with and without rounding). The multiply arithmetic all returns saturated results. It seems to me that can't hurt. Do you see any problem with using saturated MPY and MACs? By the way, the lsp.c change also fixes the TI C54x build, as expected....

...achieved with minimal pain by adding four values to the page header, immediately following the present width & height parameters (before fps_numerator & fps_denominator): pixel_width, pixel_height, x_offset, and y_offset (or somesuch). The existing width & height parameters specify (in 16x16 units as they do now) the encoded frame size, which will always be a multiple of 16x16 blocks. The new parameters should specify a rectangle within said encoded frame which correspond to the actual pixels to be displayed. The encoder is responsible for properly promoting the incoming image to a mul...

...ake sense to upstream them? I figure that as architectures get wider, we'll eventually have "all" possible combinations of widths and types, but on the other hand having code that isn't used by current backends in tree isn't great. These are the MVT's that we have added: 16x16 element (2D SIMD) 1-bit predicate registers: v256i1 16x16 element (2D SIMD) 16-bit registers: v256i16 20x20 element (2D SIMD) 16-bit registers: (we round up to v512 instead of v400): v512i16 32-bit versions of the above 16-bit registers (to represent 32-bit accumulators for MAD instructions and...

...tion> menu because diring the setup I get the following error: --- err:menubuilder:ExtractFromICO Invalid ico file format err:menubuilder:InvokeShellLinker failed to fork and exec winshelllink --- The icon is obviously ok under Windows; it is a true-color icon composed by the following bitmaps: 16x16 24bit bitmap 32x32 24 bit bitmap 32x32 32 bit bitmap with antialiasing (shows smooth borders under WinXP) 48x48 32 bit bitmap with antialiasing (shows smooth borders under WinXP) You can download and try the setup from http://download.danea.it/demo/def2006demo09b.exe Is this a known problem of Wi...

...usage 0 flags 0 nv30_miptree_create 1x1 uniform_pitch 0 usage 0 flags 0 @@ -12,6 +12,7 @@ nv30_miptree_create 256x256 uniform_pitch 0 usage 0 flags 0 nv30_miptree_create 512x512 uniform_pitch 0 usage 0 flags 0 nv30_miptree_create 48x48 uniform_pitch 192 usage 0 flags 0 +nv30_miptree_create 16x16 uniform_pitch 0 usage 0 flags 0 nv30_miptree_create 24x24 uniform_pitch 128 usage 0 flags 0 nv30_miptree_create 24x24 uniform_pitch 128 usage 0 flags 0 nv30_miptree_create 24x24 uniform_pitch 128 usage 0 flags 0 @@ -20,29 +21,24 @@ nv30_miptree_create 24x24 uniform_pitch 128 usage 0 flags 0...

...ion caused > by the shift. I also see a FIXED_POINT danger with the summation of four > mults overflowing the 32 bit before the shift. > > I can fix this by accumulating each term into a long, but if the code scales > the x[],y[] vectors to avoid this problem I could use parallel 16x16 > multiply/adds. What do you mean here? > You can see this problem with the following test case. > > for (i=0;i<40;i++) > { > x[i]=-16384; > y[i]=-32768; > } The value -32768 is not supposed to happen in vectors sent to inner_prod. > sum0=inner_prod(x, y, 40);...

...he bloat of expressing all possible combinations. How does LLVM handle 2D vectors/matrices? I haven’t moved on to v6.0.0 yet, but so far as I can tell v5.0.x only abstracts 1D vectors: N-elements of M-bits, and having types like ‘v256i16’ is not quite the same as having support for let’s say ‘v16x16i16’. Having a high-level abstraction for reasoning about NxN-elements of M-bits would be really useful/cool, especially for exotic instructions with special register allocation requirements, and for classic nested loops such as convolutions. MartinO From: llvm-dev [mailto:llvm-...

...R6/share/icons/png/hicolor/all/big.wine_doc.png /usr/X11R6/share/icons/png/hicolor/all/mini.wine_doc.png /usr/X11R6/share/icons/png/hicolor/all/big.wine.png /usr/X11R6/share/icons/png/hicolor/all/normal.wine.png /usr/X11R6/share/icons/png/hicolor/all/mini.wine.png /usr/X11R6/share/icons/png/hicolor/16x16/apps/wine_doc.png /usr/X11R6/share/icons/png/hicolor/16x16/apps/wine.png /usr/X11R6/share/icons/png/hicolor/32x32/apps/wine_doc.png /usr/X11R6/share/icons/png/hicolor/32x32/apps/wine.png /usr/X11R6/share/icons/png/hicolor/48x48/apps/wine_doc.png /usr/X11R6/share/icons/png/hicolor/48x48/apps/wine.pn...

Right, there shouldn't be a problem with undefined behavior. That said, a 64 bit implementation will work very well - in fact that's how it was done originally. The reason for the current implementation is to minimize 64-bit operations in order to improve performance on limited-width architectures. This functions gets used extensively, and I think the current implementation is faster on

First I would like to say thank you to HPA for providing some really nice features in recently syslinux version. About new functions, actually I have another radical idea, since we are in Asia, most of the users here they would like to see some local fonts for the syslinux/pxelinux menu. I am wondering is that possible, in the future, the syslinux/pxelinux menu can support CJK fonts or icon ?

...mailto:opus at xiph.org>" <opus at xiph.org<mailto:opus at xiph.org>>, Marcello Caramma <mcaramma at cisco.com<mailto:mcaramma at cisco.com>> Subject: Re: [opus] Alleged bug in Silk codec Yes those instructions exist, although they're a bit slower than the basic 16x16->32 with 32-bit accumulation (SMLABB). So I'd be surprised if the function with 64 bit accumulation would run as fast as the current code. Don't know how much we care about 16-bit platforms. And accuracy should not matter. On the other hand, a 64-bit implementation is much cleaner/sh...

.../decode, complexity 1, 8kbps, no preprocessor or jitter buffer or echo canceller (yet). >> I will go back to using fixed_generic.h for now, but it may still be >> worthwhile to make a custom version that takes advantage of the compiler >> intrinsics, which include 32-bit shifts, 16x16=32 and 32x16=32 MPY, and >> 32+16x16=32 MAC (with and without rounding). The multiply arithmetic all >> returns saturated results. It seems to me that can't hurt. Do you see >> any >> problem with using saturated MPY and MACs? > > Saturation never hurts. That...

> One thing I've noticed so far in the filter_mem2 code is the calls to > SATURATE(x, 805306368). 805306368 is 0x30000000. I was expecting that > to be on a bit boundary, say 0x3fffffff? In which case the arithmetic > saturation logic could be used. I don't think it would make that big of a difference, since the saturation is outside of the inner loop. If it's that

...ia a restricted set of operations that we have intrinsics for. -- Sean Silva > I haven’t moved on to v6.0.0 yet, but so far as I can tell v5.0.x only > abstracts 1D vectors: N-elements of M-bits, and having types like ‘v256i16’ > is not quite the same as having support for let’s say ‘v16x16i16’. > Having a high-level abstraction for reasoning about NxN-elements of M-bits > would be really useful/cool, especially for exotic instructions with > special register allocation requirements, and for classic nested loops such > as convolutions. > > > > Marti...