Loading ...
Sorry, an error occurred while loading the content.

Re: [buildcheapeeg] BWView

Expand Messages
  • Doug Sutherland
    Hi Dave, ... 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
    Message 1 of 20 , Mar 1, 2002
    • 0 Attachment
      Hi Dave,

      > 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:

      When the data first appears, you probably won't see
      much. You need to start by adjusting the brightness.
      Try 'b9' or 'b0' and work down from there. You'll
      also probably need to adjust the gain for the signal
      level display so that you can see it properly. Use
      's' and then digits until that looks okay.

      > I also have both gcc 2.95 and 3.0 installed on my system

      Youch.

      > it really looks like a completely new data set is being
      > displayed

      Perhaps the settings need to be tweaked per the tutorial.


      > I read the FFTW docs, looking for references to the 64-bit
      > library you mentioned. Except for the mention of different
      > integer sizes, I do not see where they make a distinction
      > between 32-bit/64-bit compilations. Can this really be the
      > problem? I would think your build and mine are from the
      > same vanilla setup -- ./configure, make, make install.

      According to Jim's instructions, when you build FFTW ...

      ./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.

      Dave, see this section of the FFTW FAQ:
      http://www.fftw.org/doc/fftw_6.html

      By default, FFTW is compiled for double-precision
      transforms. To work in single precision rather than
      double precision, #define the symbol FFTW_ENABLE_FLOAT
      in fftw.h (in the fftw directory) and (re)compile FFTW.
      These libraries should be linked with any program that
      uses the corresponding transforms. The required header
      files, fftw.h and rfftw.h, are located in the fftw and
      rfftw directories respectively; you may want to put
      them with the libraries, or wherever header files
      normally go on your system.

      A note for Jim: there is apparently a way to install FFTW
      for BOTH single and double precision on the same machine,
      as long as you don't use both in the SAME program.

      http://www.fftw.org/doc/fftw_6.html#SEC69

      It says that both can be installed like this:

      ./configure --enable-type-prefix [ other options ]
      make
      make install
      make clean
      ./configure --enable-float --enable-type-prefix [ other options ]
      make install

      Also see this section on pentium hacks (enable-i386-hacks)
      http://www.fftw.org/doc/fftw_6.html#SEC70

      In principle, these hacks are no longer required under gcc
      versions 2.95 and later, which automatically align the stack
      correctly (see -mpreferred-stack-boundary in the gcc manual).
      However, we have encountered a bug in the stack alignment of
      versions 2.95.[012] that causes FFTW's stack to be misaligned
      under some circumstances. The configure script automatically
      detects this bug and disables gcc's stack alignment in favor
      of our own hacks when --enable-i386-hacks is used. The fftw_test
      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 ...


      > So... now the favor from both of you. I have uploaded two
      > 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,
      > and compiled a new BWView binary (bwview-dave-shared-fftw).
      > Notice the size difference.

      Good stuff, we should be working on shared libraries.


      > In order to compile the sharable libs, you'll need to
      > make clean
      > ./configure --enable-shared
      > make
      > make install
      > and then 'mk' to get a new BWView binary.

      Cool, I will try making mine a shared version of FFTW.


      > If bwview-dave-shared-fftw works, but bwview-dave-static-fftw
      > 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.

      -- Doug
    • Doug Sutherland
      Jim, According to the FFTW FAQ, the enable-i386-hacks is for double precision transforms: The configure option --enable-i386-hacks enables specific
      Message 2 of 20 , Mar 1, 2002
      • 0 Attachment
        Jim,

        According to the FFTW FAQ, the enable-i386-hacks is for double
        precision transforms:

        The configure option --enable-i386-hacks enables specific
        optimizations for the Pentium and later x86 CPUs under gcc,
        which can significantly improve performance of double-
        precision transforms. <snip> These hacks provide a workaround
        to the incorrect alignment of local double variables in gcc.
        The compiler aligns these variables to multiples of 4 bytes,
        but execution is much faster (on Pentium and PentiumPro) if
        doubles are aligned to a multiple of 8 bytes.

        If we are doing only single precision transforms, perhaps
        we don't need to enable the pentium hacks? There seems to
        be some bugs in these hacks:

        In principle, these hacks are no longer required under gcc
        versions 2.95 and later, which automatically align the
        stack correctly (see -mpreferred-stack-boundary in the gcc
        manual). However, we have encountered a bug in the stack
        alignment of versions 2.95.[012] that causes FFTW's stack
        to be misaligned under some circumstances. The configure
        script automatically detects this bug and disables gcc's
        stack alignment in favor of our own hacks when
        --enable-i386-hacks is used.

        From http://www.fftw.org/doc/fftw_6.html#SEC70

        Can we skip the enable-i386-hacks for single precision?

        -- Doug
      • Jim Peters
        ... Yes, this is what I mentioned earlier. As I said, I haven t tried it. This looks like a good way to go (and more standard), even if we need to change the
        Message 3 of 20 , Mar 1, 2002
        • 0 Attachment
          Doug Sutherland wrote:
          > A note for Jim: there is apparently a way to install FFTW
          > for BOTH single and double precision on the same machine,
          > as long as you don't use both in the SAME program.

          Yes, this is what I mentioned earlier. As I said, I haven't tried it.
          This looks like a good way to go (and more standard), even if we need
          to change the #include "fftw.h" line or functions names or whatever.


          > 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?

          I don't think it is so sensitive to the kernel version. Most stuff
          works fine between kernel versions, as far as I am aware. However,
          the GLIBC version is pretty important, as the executable links with
          it.


          > Good stuff, we should be working on shared libraries.

          I agree -- use the --enable-shared option if it works.


          > According to the FFTW FAQ, the enable-i386-hacks is for double
          > precision transforms:
          >
          > If we are doing only single precision transforms, perhaps
          > we don't need to enable the pentium hacks?
          >
          > Can we skip the enable-i386-hacks for single precision?

          Yes, I think you are right. This may have been from when I was still
          experimenting with double-precision for the transforms.


          Cheers --

          Jim

          --
          Jim Peters (_)/=\~/_(_) jim@...
          (_) /=\ ~/_ (_)
          UazĂș (_) /=\ ~/_ (_) http://
          B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
        • Doug Sutherland
          Jim, ... It is a big deal usually between major revs like 2.0.x and 2.2.x and 2.4.x. I ve seen lots of software out there by companies like IBM and such, they
          Message 4 of 20 , Mar 1, 2002
          • 0 Attachment
            Jim,

            > I don't think it is so sensitive to the kernel version.
            > Most stuff works fine between kernel versions, as far
            > as I am aware.

            It is a big deal usually between major revs like 2.0.x
            and 2.2.x and 2.4.x. I've seen lots of software out
            there by companies like IBM and such, they usually
            have binaries for major linux revs. That used to be
            2.0.x and 2.2.x, now it's 2.2.x and 2.4.x

            > However, the GLIBC version is pretty important, as
            > the executable links with it.

            This is a real pain for binary distribution, and glibc
            is huge. On slackware it's close to 100 MB! We can't
            really have binaries for all of the glibc versions.
            Perhaps for linux we should only have a source version
            with a good build script. For Windows we can have
            binaries for the various flavours (Win9x, WinNt, Win2K).

            -- Doug
          • Dave
            ... I have tried all the brightness settings, from b0..b9. The image which is dislayed is clearly different from the image that is presented when using his
            Message 5 of 20 , Mar 1, 2002
            • 0 Attachment
              On Fri, 01 Mar 2002 02:40:42 -0600, Doug Sutherland wrote:

              >Hi Dave,
              >
              >> 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:

              I have tried all the brightness settings, from b0..b9. The image which is
              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 system
              >
              >Youch.

              I know; sometimes I live dangerously. :-)

              >According to Jim's instructions, when you build FFTW ...
              >
              > ./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.

              Now, that I missed. I did enable the i386 hacks during the compilation, but
              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!

              >
              >Dave, see this section of the FFTW FAQ:
              >http://www.fftw.org/doc/fftw_6.html
              >
              > By default, FFTW is compiled for double-precision
              > transforms. To work in single precision rather than

              Yep, and I let it default to that. :-(

              >A note for Jim: there is apparently a way to install FFTW
              >for BOTH single and double precision on the same machine,
              >as long as you don't use both in the SAME program.

              I saw that last night, also. I am curious... why would we want both single and
              double floating point percision? Are there speed trade-offs? Calculation
              accuracies?

              > of our own hacks when --enable-i386-hacks is used. The fftw_test
              > 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 ...

              No, I did not. I will do a couple of test compilations both with gcc 2.95 and
              gcc 3.0. I'll post the results later.

              >> So... now the favor from both of you. I have uploaded two
              >> 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?

              That's why I was able to use Jim's binary then. My kernel is 2.2.19 and Glibc
              is 2.2.

              >> So I recompiled FFTW so that it created the sharable libraries,
              >> and compiled a new BWView binary (bwview-dave-shared-fftw).
              >> Notice the size difference.
              >
              >Good stuff, we should be working on shared libraries.

              Note, though, that while a wonderful thing, they can also be difficult if not
              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-fftw
              >> 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.

              I'm sorry, I really can't send those screen shots now, or even test the your
              feedback concerning the recompilation using single percision floats. The
              latter sounds the more likely fix. Thanks, Doug!

              Dave.
            • Doug Sutherland
              Dave, ... I don t think we would want both. The issue was whether to make FFTW part of OpenEEG or keep it as a separate package. My argument was that people
              Message 6 of 20 , Mar 1, 2002
              • 0 Attachment
                Dave,

                > I am curious... why would we want both single and double
                > floating point percision? Are there speed trade-offs?
                > Calculation accuracies?

                I don't think we would want both. The issue was whether
                to make FFTW part of OpenEEG or keep it as a separate
                package. My argument was that people may want to use
                FFTW and SDL for other things besides OpenEEG. Since
                FFTW can exist as both single and double precision on
                the same machine, there is no conflict. In other words,
                the fact that we need single precision doesn't stop
                people from using either single or double elsewhere.

                Namaste,
                Doug
              Your message has been successfully submitted and would be delivered to recipients shortly.