Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #2327

Re: need help/advice/code review for GPU DWT implementation

Show all headers | View raw

Hi Thomas,

Thanks very much for your reply. I really appreciate hearing about your experience with GPU acceleration, it is really "gold" for me as I try to move my
library forward. 

I read an interesting fact about the memory bottleneck: as you probably know, they will shortly be releasing PCIe 4.0 hardware, with double the memory bandwidth of 3.0. One site stated that this will mean *no improvement* for gamers, because PCI video cards still have trouble saturating the PCI 2.0 bandwidth. So it looks like we may be stuck with this sorry state of affairs for a while. 

> > I believe that the GPU starts to beat out the CPU as the image size grows; 4K
> 
> > digital video, for example. For smaller images the CPU will win. For now, at least. There are new developments like NVLink from nVidia, which claims to remove the PCI bottleneck. Although nVidia OpenCL support is terrible, so this
> 
> > may not benefit OpenCL libraries.
> 
> 
> 
> Actually, that pretty much depends on the architecture. On a standard 
> 
> GPU that sits behind the PCIe bus, the time required to get the data on 
> 
> and off the GPU is approximately identical to the time required to do 
> 
> the lifting. Thus, if you have to transform a single image, it does not 
> 
> pay. The overall computation time on Linux is a little bit faster with 
> 
> the GPU compared to CPU only, and the overall computation time on 
> 
> windows is with GPU slower than with the CPU only. Difference is that 
> 
> the per-call overhead into the OpenCL API is rather huge on windows, 
> 
> whereas Linux is pretty close to the metal.
> 

Interesting, I wonder why windows is so slow. My main target is decomopression on windows. 

> 
> Note that the memory copy overhead and the transformation overhead scale 
> 
> in the same way with the image size, thus there is no win or loose for 
> 
> big images, it stays a problem.
> 
> 
> If you have to transform multiple images sequentially, e.g. a movie 
> 
> (note that Digital Cinema uses JPEG 2000, so this is a realistic use 
> 
> case) results are rather different. You can then overlay memory 
> 
> operations of the next image with the transformation of the previous image.
> 
> 

 Yes, if you can pipeline the memory transfer and the number crunching, then this is good. One application I have been thinking about is real-time digital cinema compression, where pipelining could make it feasible.

> 
> It would be an advantage to use a on-CPU GPU such as the GPUs integrated 
> 
> into the recent AMD CPUs. Unfortunately, these GPUs are much less 
> 
> powerful than their PCIe cousins, and hence not an adequate replacement 
> 
> either. Things would turn out to be benefical as soon as on-chip GPUs 
> 
> would become powerful enough. Unfortunately, such GPUs are currently 
> 
> seen as "good enough" solutions for office PCs and not as replacement 
> 
> for gaming (which drives the GPU market, like it or not), so it's not 
> 
> going to change soon.
> 
> 

One bright spot may be Intel. Their newest integrated GPUs are
starting to match the performance of low end dedicated cards, and the memory bandwidth is about twice as large. I am using the Intel OpenCL SDK for my project, and their sofware is quite mature.  So, looking to the future, I think/hope that the integrated GPUs will get good enough to make this all worthwhile. 


> 
> > Besides the PCI bottleneck, there is the serial nature of parts of the JPEG 2000
> 
> > codec. In this area, the CPU also wins. So, another idea is to use the heterogenous nature of OpenCL to use both CPU and GPU in tandem.
> 
> 
> 
> That's what I did. Color transformation, wavelet, quantization on the 
> 
> GPU, EBCOT multithreaded on the CPU. No dice. It's really interesting to 
> 
> see where the time goes. It's really the memory operations that kill the 
> 
> performance, everything else is nice.
> 

Interesting. Because I am focusing on decompression, I found this article useful, although a lot of detail was missing:

High Performance Parallel JPEG2000 Streaming Decoder Using GPGPU-CPU Heterogeneous System.
Roto Le, Joseph L. Mundy, and R. Iris Bahar. ASAP, page 16-23. IEEE Computer Society, (2012)


> > By the way, I have made a little more progress since my post; 5,3 single level DWT is almost working properly; I see some artifacts near the image boundary,
> 
> > but a roundtip forward and reverse (mostly) works.
> 
> 
> 
> Good. BTW, there is a CUDA implementation of JPEG 2000 (CudaJ2K), comes 
> 
> here from our campus (Stuttgart) as well. To keep the long story short, 
> 
> it's approximatly as fast as a two-times multithreaded CPU-only JPEG 
> 
> 2000 code. I used four threads, my OpenCL code is approximately twice as 
> 
> fast as their CUDA code.
> 

Yes, I am familiar with Cuj2k. It is a shame it is no longer worked on. Also, I understand that their compression codec does not meet JPEG 2000 conformance.

> 
> 
> > One question you might be able to answer for me: for the lifting technique, does the order of the horizontal and the vertical 1D DWT matter? If I perform 1D
> 
> > horizontal pass, and then a 1D vertical pass, is this equvalent to a 1D vertical pass followed by a 1D horizontal pass?
> 
> 
> 
> For the lossless 5/3, the answer is that the order matters because the 
> 
> precise order of rounding matters for the end result. If you swap 
> 
> horizontal/vertical, you can get small round-off errors that make your 
> 
> code lossy. That was one thing that caused a small headache, but I don't 
> 
> remember which order was easier to do.
> 
> 
> 
> For the 9/7, it does not. Or at least, the difference is so small that 
> 
> any error you pick up by that is negligible compared to the quantization 
> 
> error.

Thanks for the explanation. The j2k standard must dictate the order of horizontal and vertical, then, or a lifting codec would not be able to decompress images compressed with other libraries. Do you know which is the correct order?  Because, the CUDA libary I am porting does the vertical transform first, for the forward DTW.

Best Regards,
Aaron

Back to comp.compression | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

need help/advice/code review for GPU DWT implementation boxerab@gmail.com - 2014-05-15 18:22 -0700
  Re: need help/advice/code review for GPU DWT implementation Thomas Richter <thor@math.tu-berlin.de> - 2014-05-16 09:18 +0200
    Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-05-20 10:42 -0700
      Re: need help/advice/code review for GPU DWT implementation Thomas Richter <thor@math.tu-berlin.de> - 2014-05-21 09:44 +0200
        Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-05-21 20:42 -0700
          Re: need help/advice/code review for GPU DWT implementation Thomas Richter <thor@math.tu-berlin.de> - 2014-05-22 09:57 +0200
            Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-05-23 07:46 -0700
    Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-06-11 13:13 -0700
      Re: need help/advice/code review for GPU DWT implementation Thomas Richter <thor@math.tu-berlin.de> - 2014-06-12 08:17 +0200
        Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-06-12 07:34 -0700
        Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-08-01 20:28 -0700
          Re: need help/advice/code review for GPU DWT implementation Thomas Richter <thor@math.tu-berlin.de> - 2014-08-02 07:41 +0200
            Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-08-02 18:01 -0700
              Re: need help/advice/code review for GPU DWT implementation Thomas Richter <thor@math.tu-berlin.de> - 2014-08-03 22:06 +0200
                Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-08-03 19:50 -0700
            Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-08-05 06:31 -0700
              Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-08-30 20:18 -0700
                Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-09-24 19:34 -0700
  Re: need help/advice/code review for GPU DWT implementation Fibonacci Code <anglikai@gmail.com> - 2014-05-28 01:07 -0700
    Re: need help/advice/code review for GPU DWT implementation Aaron Boxer <boxerab@gmail.com> - 2014-05-28 05:23 -0700

csiph-web