2383Re: [buildcheapeeg] BWView
- Mar 1, 2002On Fri, 01 Mar 2002 02:40:42 -0600, Doug Sutherland wrote:
>Hi Dave,I have tried all the brightness settings, from b0..b9. The image which is
>> I have spent this evening trying to resolve the display
>> disparity between Jim-P's binary version and mine
>What is the display disparity? Did you try adjusting the
>brightness, this is key, as outlined in Jim's tutorial.
>When I first tried BWView all I saw was darkness, with
>just a bit of grey here and there. From the tutorial:
dislayed is clearly different from the image that is presented when using his
original binary. I sent some screen shots up to my server a few days ago, but
have deleted them. I am now on my way out the door for the day, but will send
some more back up later if nothing else clarifies concerning this issue.
>> I also have both gcc 2.95 and 3.0 installed on my systemI know; sometimes I live dangerously. :-)
>According to Jim's instructions, when you build FFTW ...Now, that I missed. I did enable the i386 hacks during the compilation, but
> ./configure --enable-float --enable-i386-hacks
> This is required because I use the 32-bit floating
> point version of the library, rather than the
> default 64-bit one.
let the build default to double percision floats. Well, you might have just
targeted the issue. Enabling the hacks did not change the display I was
seeing, which makes sense since they only effect the performance of the
calculations, but leave the correctness of the calculations the same. I wish I
had time this morning to test the theory!
>Yep, and I let it default to that. :-(
>Dave, see this section of the FFTW FAQ:
> By default, FFTW is compiled for double-precision
> transforms. To work in single precision rather than
>A note for Jim: there is apparently a way to install FFTWI saw that last night, also. I am curious... why would we want both single and
>for BOTH single and double precision on the same machine,
>as long as you don't use both in the SAME program.
double floating point percision? Are there speed trade-offs? Calculation
> of our own hacks when --enable-i386-hacks is used. The fftw_testNo, I did not. I will do a couple of test compilations both with gcc 2.95 and
> program outputs speed measurements that you can use to see if
> these hacks are beneficial.
>Dave, did you try running the FFTW tests? After installation
>just do make check ...
gcc 3.0. I'll post the results later.
>> So... now the favor from both of you. I have uploaded twoThat's why I was able to use Jim's binary then. My kernel is 2.2.19 and Glibc
>> binaries to my web site (these are Linux-only, folks). Could
>> you run these on your systems and see if your results match
>> the original binary that you, Jim, included in your release?
>The binaries will only work if we are on same major kernel
>revision and same glibc version. Jim's binary would not
>run on my system because I'm using Glibc 2.1.3 and Jim is
>using Glibc 2.2. So what kernel and Glibc version are you
>using, and what version of the compiler?
>> So I recompiled FFTW so that it created the sharable libraries,Note, though, that while a wonderful thing, they can also be difficult if not
>> and compiled a new BWView binary (bwview-dave-shared-fftw).
>> Notice the size difference.
>Good stuff, we should be working on shared libraries.
managed well. This is a good example of what we are experiencing now, in terms
in incompatibility. It becomes a real issue if a client has one program based
on one set of shared libraries (let's say that the program is not as well
maintained and as up-to-date), and another package that is based on a newer
set. It is not easy to get them to coexist. It can be done using
LD_LIBRARY_PATH, but there are issues surrounding the use of that. I wish I
had more time, but you are probably familiar with all of this.
>> If bwview-dave-shared-fftw works, but bwview-dave-static-fftwI'm sorry, I really can't send those screen shots now, or even test the your
>> does not, then we have identified FFTW as the problem.
>I still don't understand what the disparity is. I will try
>your binaries but I'm guessing they will screech to a halt
>due to incompatibilites in libraries.
feedback concerning the recompilation using single percision floats. The
latter sounds the more likely fix. Thanks, Doug!
- << Previous post in topic Next post in topic >>