search for: zanders

Thomas Zander wrote: > If you want to share the patch, I am happy to repeat some testing on > Sandy Bridge and Core2 with clang. The patch changes many files, libFLAC/bitwriter.c and test_libFLAC/bitwriter.c among them. So now I wait for the decision for patches #3 and #4 that I posted yesterday. > The slower decoding speed for 24 bit content on x86_64 seems > surprising, but

On 12/08/16 12:24 AM, Thomas Zander wrote: > On 7 December 2016 at 21:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: >> lvqcl.mail wrote: >> >>> "make -f Makefile.lite" also doesn't work out of box. >> >> Didn't work for the 1.3.1 release either. Makes me wonder why we even >> keep it around. > > Because it works on

Hello, One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM at boot time but, if I blacklist the module and load it myself later on, it always succeeds. To make things weirder, the same card works great on another computer. Here is the relevant code in Nouveau to fetch the vbios from PROM:

On 29 December 2015 at 08:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > I would suggest: > > #if SIZEOF_VOIDP == 8 I believe this is not portable. At least on my machine ("4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)") it's not defined. Probably this one comes closest: #define __SIZEOF_POINTER__ 8 Riggs

On Dec 30, 2015, at 3:09 AM, Thomas Zander <thomas.e.zander at googlemail.com> wrote: > On 29 December 2015 at 21:50, lvqcl <lvqcl.mail at gmail.com> wrote: >> So, does it make sense to #define FLAC__BYTES_PER_WORD (in bitreader.c) >> as 4 for 32-bit and as 8 for 64-bit targets? > > Your tests so far imply this is a sensible default. > I'd say go ahead. We

On 14 March 2016 at 09:02, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > commit a9f84425cfd5d1dbfb564730ca80d0b588cb4f24 > Author: Erik de Castro Lopo <erikd at mega-nerd.com> > Date: Mon Mar 14 18:14:31 2016 +1100 > > libFLAC/cpu.c: Use `sigemptyset` instead of `__sigemptyset` > > The former is POSIX while the later is a GNU

Thomas Zander wrote: > In any case, the disable-SSE matter is still important. People are > still using flac on x86 machines without SSE, for instance AMD Geode > CPUs seem to live forever. libFLAC detects CPU SSE support in runtime, so --disable-sse is necessary for cuch CPUs only because it disables -msse2 switch. Maybe it makes sense to add new switch, --no-force-sse2 or

On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote: > > Hello, > > One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM > at boot time but, if I blacklist the module and load it myself later on, > it always succeeds. To make things weirder, the same card works great on > another computer. > > Here is the relevant code in Nouveau to fetch

On Dec 7, 2015, at 4:21 PM, Gernot Zander <debian at scorpio.in-berlin.de> wrote: > > Hi, > > am 7 Dez schrieb Marks, Connor: >> Well I just need to monitor the UPS battery for testing and I do about >> 10 UPS's a day. So having to restart my computer every time gets old >> real quick. > > In that case - what about not starting nut-client (upsmon)

I have just recently gotten NUT to work on my system, with much assistance from Charles Lepple, and am very?grateful for his assistance. ? I now have a question regarding the NUT-Monitor program. ?There is a tool in the GUI that is for sending devicecommands. ?I can't get it to work. ?Whenever I try to send a command I get the following message: Failed to send <command> ?(ERR USERNAME

Hi, I encountered a problem when I am trying to write my own function which contains another function. To simplify a problem, I tried the following simplified function, hope someone can idenfity the problem for me. I have a simple data frame called "testdata" as following: >

Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA, let's only use 32-bit accesses to fetch the vbios from PROM. This fixes vbios fetching on my nve7 which failed in certain specific conditions. I suggest we Cc stable, for all kernels they still maintain after the big rewrite. Suggested-by: Christian Zander <czander at nvidia.com> Signed-off-by: Martin Peres

I am also philosophically opposed to changing the specification. That said, there's nothing wrong with adding a note to the specification about the common implementations, particularly the reference library. Then, future developers will know both the precise specification and still have the warning that they risk incompatibility by deviating from the reference implementation. I own devices

I wrote a patch that enables FLAC__BYTES_PER_WORD==8 in libFLAC/bitreader.c and libFLAC\bitwriter.c. The tests were done on an Intel Nehalem CPU, and flac was compiled with CGG 4.9.x. Average speed increase for FLAC__BYTES_PER_WORD change from 4 to 8: Decoding speed: ia32 architecture 16-bit .flac: -15% 24-bit .flac: -11% x86-64 architecture 16-bit .flac:

Thomas Zander wrote: > ... and this probably won't be the last time we'd need to handle special cases. > Do we really need to handle this at all? Entangling CPU-arch-dependent > #ifdefs with input sample size (see "tuned for N-bit input" a few > lines below" seems weird. > IMHO finding the rice parameter should be independent of the cpu arch > unless there

Dave Yeo wrote: > Doesn't SSE support imply SSE2+ support? Not for the CPU. Just because a CPU supports SSE, does not mean it is guaranteed to support SSE2+. For OS support, I'm not sure. Didn't later version of SSE add new registers? > I have a '96 install of an OS, it has been upgraded until end of life, > and it handles SSE4+ instructions fine even though the

Subject line says it all. Opinions? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Thomas Zander wrote: > I'd say let's have a release candidate. More often than not, some > issues turn up due to the exposure to a larger user base and, hence, > test cases. Ok, coming up. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

lvqcl.mail wrote: > "make -f Makefile.lite" also doesn't work out of box. Didn't work for the 1.3.1 release either. Makes me wonder why we even keep it around. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

On Dec 8, 2016, at 12:59 AM, Dave Yeo <dave.r.yeo at gmail.com> wrote: > On 12/08/16 12:24 AM, Thomas Zander wrote: >> On 7 December 2016 at 21:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: >>> lvqcl.mail wrote: >>> >>>> "make -f Makefile.lite" also doesn't work out of box. >>> >>> Didn't work for