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

Groups > comp.compression > #2321 > unrolled thread

need help/advice/code review for GPU DWT implementation

Back to article view | Back to comp.compression

Contents

  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

#2321 — need help/advice/code review for GPU DWT implementation

Hello List, 

I am working on an open source DWT implementation written in OpenCL. 
It is a port of a CUDA project. 

https://github.com/OpenCodec/ocldwt 

The CUDA project handles 5,3 and 9,7 DWTs using the "lifting" technique. 

I need this for my other project, an OpenCL JPEG2000 library. 

I have finished the port for 5,3, but the library is not working properly. 
I see lines and strips of grey, but not a discernable dyadic decomposition of the image, as I would expect.  I am a signal processing neophyte, so sort of 
stuck right now. 

If any kind soul is interested in reviewing my code, trying to grok the algorithm being used, or anything, it would be greatly appreciated. 

Thanks, 
Aaron 

[toc] | [next] | [standalone]

#2322

Hi Aaron,

> I am working on an open source DWT implementation written in OpenCL.
> It is a port of a CUDA project.
>
> https://github.com/OpenCodec/ocldwt
>
> The CUDA project handles 5,3 and 9,7 DWTs using the "lifting" technique.
>
> I need this for my other project, an OpenCL JPEG2000 library.

Actually, there are a couple of works in this direction, most notably 
the one by J.Matela:

\bibitem{MatelaDCC} J.~Matela, V.~Rusnak, P.~Holub: ``Efficient JPEG2000
   EBCOT Context Modeling for Massively Parallel Architectures'', Proc. of
Data Compression Conference (DCC), pp. 423-432, (2011)
\bibitem{MatelaSPIE} J.~Matela, P.~Holub, M.~Jirman, M.~Srom: ``GPU-specific
   reformulations of image compression algorithms'', Proc. of SPIE 8499,
   Appl. of Digital Image Proc. XXXV, (2012)

However, what I find is that you might get a very fast wavelet codec, 
but you still need to get the data on the GPU, and back from it. The 
time required to transfer the data onto the GPU and back from it is 
typically as large as doing the transformation. The net result of my 
study is that it isn't worth it. By using specialized CPU instructions, 
you can do as fast as the GPU, including the overhead of starting up the 
GPU. It doesn't pay.

If you want to review a paper that lists a couple of strategies for 
doing the wavelet transform, here is one:

\bibitem{bharatkumar} Bharatkumar Sharma, Naga Vydyanathan: ``Parallel
   Discrete Wavelet Transformation using the Open Computing Language: a
   performance and portability study'', Proc. of Parallel \& Distributed
   Processing, Workshops and Phd Forum (IPDPSW), 2010 IEEE International
   Symposium on, (2010)

This paper I found one of the best. To keep the story short, the best 
strategy is a windowed approach, same as the one done by Jiri Matela.

> I have finished the port for 5,3, but the library is not working properly.
> I see lines and strips of grey, but not a discernable dyadic decomposition of the image, as I would expect.  I am a signal processing neophyte, so sort of
> stuck right now.

Sorry, while I do have an implementation of the 5/3 and 9/7 all in 
OpenCL and properly working, I afraid I'm not allowed to pass them out, 
it's not open source. But again, as I said, it's not worth doing as long 
as the GPU is still a separate unit on the PCI bus and the OpenCL 
by-call overhead is as large as it is today. Don't. If you want to see 
my results, here they are:

Th. Richter: "Coding Strategies and Performance Analysis of GPU 
Accelerated Image Compression", Proc. of IEEE Picture Coding Symposium 
(PCS), 2013.

Greetings,

Thomas

[toc] | [prev] | [next] | [standalone]

#2325

Hi Thomas,

Thanks for your reply, very interesting. I will take a look at these papers.

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.

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.

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.

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?  


Cheers,
Aaron





On Friday, May 16, 2014 3:18:31 AM UTC-4, Thomas Richter wrote:
> Hi Aaron,
> 
> 
> 
> > I am working on an open source DWT implementation written in OpenCL.
> 
> > It is a port of a CUDA project.
> 
> >
> 
> > https://github.com/OpenCodec/ocldwt
> 
> >
> 
> > The CUDA project handles 5,3 and 9,7 DWTs using the "lifting" technique.
> 
> >
> 
> > I need this for my other project, an OpenCL JPEG2000 library.
> 
> 
> 
> Actually, there are a couple of works in this direction, most notably 
> 
> the one by J.Matela:
> 
> 
> 
> \bibitem{MatelaDCC} J.~Matela, V.~Rusnak, P.~Holub: ``Efficient JPEG2000
> 
>    EBCOT Context Modeling for Massively Parallel Architectures'', Proc. of
> 
> Data Compression Conference (DCC), pp. 423-432, (2011)
> 
> \bibitem{MatelaSPIE} J.~Matela, P.~Holub, M.~Jirman, M.~Srom: ``GPU-specific
> 
>    reformulations of image compression algorithms'', Proc. of SPIE 8499,
> 
>    Appl. of Digital Image Proc. XXXV, (2012)
> 
> 
> 
> However, what I find is that you might get a very fast wavelet codec, 
> 
> but you still need to get the data on the GPU, and back from it. The 
> 
> time required to transfer the data onto the GPU and back from it is 
> 
> typically as large as doing the transformation. The net result of my 
> 
> study is that it isn't worth it. By using specialized CPU instructions, 
> 
> you can do as fast as the GPU, including the overhead of starting up the 
> 
> GPU. It doesn't pay.
> 
> 
> 
> If you want to review a paper that lists a couple of strategies for 
> 
> doing the wavelet transform, here is one:
> 
> 
> 
> \bibitem{bharatkumar} Bharatkumar Sharma, Naga Vydyanathan: ``Parallel
> 
>    Discrete Wavelet Transformation using the Open Computing Language: a
> 
>    performance and portability study'', Proc. of Parallel \& Distributed
> 
>    Processing, Workshops and Phd Forum (IPDPSW), 2010 IEEE International
> 
>    Symposium on, (2010)
> 
> 
> 
> This paper I found one of the best. To keep the story short, the best 
> 
> strategy is a windowed approach, same as the one done by Jiri Matela.
> 
> 
> 
> > I have finished the port for 5,3, but the library is not working properly.
> 
> > I see lines and strips of grey, but not a discernable dyadic decomposition of the image, as I would expect.  I am a signal processing neophyte, so sort of
> 
> > stuck right now.
> 
> 
> 
> Sorry, while I do have an implementation of the 5/3 and 9/7 all in 
> 
> OpenCL and properly working, I afraid I'm not allowed to pass them out, 
> 
> it's not open source. But again, as I said, it's not worth doing as long 
> 
> as the GPU is still a separate unit on the PCI bus and the OpenCL 
> 
> by-call overhead is as large as it is today. Don't. If you want to see 
> 
> my results, here they are:
> 
> 
> 
> Th. Richter: "Coding Strategies and Performance Analysis of GPU 
> 
> Accelerated Image Compression", Proc. of IEEE Picture Coding Symposium 
> 
> (PCS), 2013.
> 
> 
> 
> Greetings,
> 
> 
> 
> Thomas

[toc] | [prev] | [next] | [standalone]

#2326

Am 20.05.2014 19:42, schrieb Aaron Boxer:
> Hi Thomas,
>
> Thanks for your reply, very interesting. I will take a look at these papers.
>
> 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.

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.

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.

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

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

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

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#2327

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

[toc] | [prev] | [next] | [standalone]

#2328

Hi Aaron,

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

Hard to tell. Most games fit their graphics/textures into the GPU RAM 
first, and then work from there. Thus, the PCIe bottleneck is not much 
an issue for them. As soon as the game needs to offload graphics into 
main memory, things are getting too slow no matter what the bandwidth is.

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

Too much overhead, too much legacy, too much administration. No wonder 
AMD started the "mantle" initiative to get rid of all this. Of course, 
for games things aren't quite as bad because many calls can be 
interleaved, and the actual GPU algorithm is more complicated than a DWT.

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

You should probably talk to the Fraunhofer IIS in Erlangen, Germany. 
They offer a GPU-accelerated JPEG 2000 decoder for digital cinema. If 
you're interested, I can make a contact (I know the guys there, too).

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

Well, hard to say. Of course, their GPUs are getting better, but that's 
still the low-end, suitable for office PCs. Gaming isn't the core 
business of intel. High-performance computing might be, which is 
probably why they are interested in this. What I currently get from them 
is not even closely sufficient to beat an optimized CPU version.

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

Well, I believe it should be conforming, but I don't actually remember 
because it's been a while. The core focus of the IPVS (the institute 
that made the implementation) is rather FPGAs than GPU hardware, that's 
why it is no longer developed.

You might be able to get a better version of a CUDA based JPEG 2000 from 
J. Matela (I quoted his article above) if you are interested. I still 
should have his mail somewhere. I'm not clear about the legal status of 
this code, i.e. whether it's free or not, but you could ask.

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

The standard says that decompression has to do horizontal first, then 
vertical. This is figure F-6, subclause F.3.2.

Greetings,

Thomas Richter

[toc] | [prev] | [next] | [standalone]

#2329

Hi Thomas,


> > 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.
> 
> 
> Hard to tell. Most games fit their graphics/textures into the GPU RAM 
> 
> first, and then work from there. Thus, the PCIe bottleneck is not much 
> 
> an issue for them. As soon as the game needs to offload graphics into 
> 
> main memory, things are getting too slow no matter what the bandwidth is.

Makes sense, thanks.

> > Interesting, I wonder why windows is so slow. My main target is decomopression on windows.
> 
> 
> 
> Too much overhead, too much legacy, too much administration. No wonder 
> 
> AMD started the "mantle" initiative to get rid of all this. Of course, 
> 
> for games things aren't quite as bad because many calls can be 
> 
> interleaved, and the actual GPU algorithm is more complicated than a DWT.
> 
> 

Mantle looks cool. But it is AMD only, and there is no hope of nVidia cooperating on a standard :) 


> 
> >
> 
> >   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.
> 
> 
> 
> You should probably talk to the Fraunhofer IIS in Erlangen, Germany. 
> 
> They offer a GPU-accelerated JPEG 2000 decoder for digital cinema. If 
> 
> you're interested, I can make a contact (I know the guys there, too).
> 

Thanks for the offer, Thomas.  I may take you up on it once my library is
working properly, and I start experimenting with DCP.


> 
> > 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.
> 
> 
> 
> Well, hard to say. Of course, their GPUs are getting better, but that's 
> 
> still the low-end, suitable for office PCs. Gaming isn't the core 
> 
> business of intel. High-performance computing might be, which is 
> 
> probably why they are interested in this. What I currently get from them 
> 
> is not even closely sufficient to beat an optimized CPU version.
> 

Interesting. When you mention optimized CPU, how did you optimize? Have you tried your OpenCL code on Intel CPU? If so, how did it perform?

> 
> 
> > 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.
> 
> 
> 
> Well, I believe it should be conforming, but I don't actually remember 
> 
> because it's been a while. The core focus of the IPVS (the institute 
> 
> that made the implementation) is rather FPGAs than GPU hardware, that's 
> 
> why it is no longer developed.
> 
> 

Makes sense. I believe it was a student project.

> 
> You might be able to get a better version of a CUDA based JPEG 2000 from 
> 
> J. Matela (I quoted his article above) if you are interested. I still 
> 
> should have his mail somewhere. I'm not clear about the legal status of 
> 
> this code, i.e. whether it's free or not, but you could ask.
> 

I'm pretty sure the code is not publicly available: Jiri Matela has started 
a private company to sell real time GPU j2k encoders for the digital cinema
market.

> 
> 
> > 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.
> 
> 
> 
> The standard says that decompression has to do horizontal first, then 
> 
> vertical. This is figure F-6, subclause F.3.2.
> 

Thanks.

I have a few more questions: How did you measure occupancy and bank conflicts
for your OpenCL code?  What development tools did you use?

Cheers,
Aaron 

[toc] | [prev] | [next] | [standalone]

#2375

On Friday, May 16, 2014 3:18:31 AM UTC-4, Thomas Richter wrote:
> Hi Aaron,
> 
> 
> 
> > I am working on an open source DWT implementation written in OpenCL.
> 
> > It is a port of a CUDA project.
> 
> >
> 
> > https://github.com/OpenCodec/ocldwt
> 
> >
> 
> > The CUDA project handles 5,3 and 9,7 DWTs using the "lifting" technique.
> 
> >
> 
> > I need this for my other project, an OpenCL JPEG2000 library.
> 
> 
> 
> Actually, there are a couple of works in this direction, most notably 
> 
> the one by J.Matela:
> 
> 
> 
> \bibitem{MatelaDCC} J.~Matela, V.~Rusnak, P.~Holub: ``Efficient JPEG2000
> 
>    EBCOT Context Modeling for Massively Parallel Architectures'', Proc. of
> 
> Data Compression Conference (DCC), pp. 423-432, (2011)
> 
> \bibitem{MatelaSPIE} J.~Matela, P.~Holub, M.~Jirman, M.~Srom: ``GPU-specific
> 
>    reformulations of image compression algorithms'', Proc. of SPIE 8499,
> 
>    Appl. of Digital Image Proc. XXXV, (2012)
> 

Thomas, did you implement the algorithm described in the first paper you listed above? I would like to try. The paper mentions an open source project called
bpcuda that the authors worked on, but it seems to no longer exist.

Regards,
Aaron

[toc] | [prev] | [next] | [standalone]

#2381

Am 11.06.2014 22:13, schrieb Aaron Boxer:

>
> Thomas, did you implement the algorithm described in the first paper you listed above? I would like to try. The paper mentions an open source project called
> bpcuda that the authors worked on, but it seems to no longer exist.

I implemented a windowed DWT, which is the most efficient method for GPU 
dwts. Basically, you need to load an entire window from global memory to 
shared memory, then process it there, then push the processed data back. 
This is also the method Jiri uses, and also the method several papers 
found the most efficient. It sounds a bit strange that you waste so much 
time moving data from global to shared memory instead of overlaying this 
operation with the DWT, but it really works better this way since it 
allows a higher degree of parallelism in the actual wavelet, and it 
allows the memory interface to use block/burst transfers to access 
global memory.

For reference, I used a code called "gpudwt" which you might also find 
on the web. It is a cuda code, though, and it looks more complicated 
than necessary, though is essentially the same algorithm.

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#2382

> 
> > Thomas, did you implement the algorithm described in the first paper you listed above? I would like to try. The paper mentions an open source project called
> 
> > bpcuda that the authors worked on, but it seems to no longer exist.
> 
> 
> 
> I implemented a windowed DWT, which is the most efficient method for GPU 
> 
> dwts. Basically, you need to load an entire window from global memory to 
> 
> shared memory, then process it there, then push the processed data back. 
> 
> This is also the method Jiri uses, and also the method several papers 
> 
> found the most efficient. It sounds a bit strange that you waste so much 
> 
> time moving data from global to shared memory instead of overlaying this 
> 
> operation with the DWT, but it really works better this way since it 
> 
> allows a higher degree of parallelism in the actual wavelet, and it 
> 
> allows the memory interface to use block/burst transfers to access 
> 
> global memory.
> 
> 
> 
> For reference, I used a code called "gpudwt" which you might also find 
> 
> on the web. It is a cuda code, though, and it looks more complicated 
> 
> than necessary, though is essentially the same algorithm.
> 

Thanks. I did find this project and I am making use of it. I had to fix a few
bugs, and the lossless dwt is still broken.

I was actually wondering about the bit plane coder: did you make use of the parallel bpc described below ?

\bibitem{MatelaDCC} J.~Matela, V.~Rusnak, P.~Holub: ``Efficient JPEG2000 
   EBCOT Context Modeling for Massively Parallel Architectures'', Proc. of 
Data Compression Conference (DCC), pp. 423-432, (2011) 

Also, regarding the PCI bottleneck: for decoding, it is most likely being used for display purposes, in which case the OpenCL buffer can be
displayed on the screen quite rapidly because it can inter-operate with OpenGL,
so there is only the cost of moving the data onto the card.

Cheers,
Aaron

[toc] | [prev] | [next] | [standalone]

#2470

Hi Thomas,

Greetings! I am still hammering away at my OpenCL implementation of
the wavelet transform.

I was wondering if you could provide some insight into the following situation:

My current algorithm uses the lifting technique, with global and local memory buffers, as you describe above:

1) threads perform coalesced reads from global memory to fill a small local memory buffer
2) threads  perform lifting steps on this local buffer
3) local buffer is written back to global memory when complete.

I am looking into changing to OpenCL 2d images instead of buffers. The advantages are :

1) automatic mirroring at boundaries
2) 2d spacial caching
3) RGB values can be stored and read together, and all RGB channels can be
concurrently transformed using vector operations

Caveat: with OpenCL 1.2, an image is either read or write, not read/write.

Reading from images should be much faster than from global memory, because of caching. So, I would like to try getting rid of the local memory buffer, and perform a convolution instead. Is there a convolution that is equivalent to lifting for the 5/3 and 9/7 dwt transforms? Is this feasible, do you think?

Thanks very much,
Aaron




On Thursday, June 12, 2014 2:17:46 AM UTC-4, Thomas Richter wrote:
> Am 11.06.2014 22:13, schrieb Aaron Boxer:
> 
> 
> 
> >
> 
> > Thomas, did you implement the algorithm described in the first paper you listed above? I would like to try. The paper mentions an open source project called
> 
> > bpcuda that the authors worked on, but it seems to no longer exist.
> 
> 
> 
> I implemented a windowed DWT, which is the most efficient method for GPU 
> 
> dwts. Basically, you need to load an entire window from global memory to 
> 
> shared memory, then process it there, then push the processed data back. 
> 
> This is also the method Jiri uses, and also the method several papers 
> 
> found the most efficient. It sounds a bit strange that you waste so much 
> 
> time moving data from global to shared memory instead of overlaying this 
> 
> operation with the DWT, but it really works better this way since it 
> 
> allows a higher degree of parallelism in the actual wavelet, and it 
> 
> allows the memory interface to use block/burst transfers to access 
> 
> global memory.
> 
> 
> 
> For reference, I used a code called "gpudwt" which you might also find 
> 
> on the web. It is a cuda code, though, and it looks more complicated 
> 
> than necessary, though is essentially the same algorithm.
> 
> 
> 
> Greetings,
> 
> 	Thomas

[toc] | [prev] | [next] | [standalone]

#2471

Am 02.08.2014 05:28, schrieb Aaron Boxer:
> Hi Thomas,
>
> Greetings! I am still hammering away at my OpenCL implementation of
> the wavelet transform.
>
> I was wondering if you could provide some insight into the following situation:
>
> My current algorithm uses the lifting technique, with global and local memory buffers, as you describe above:
>
> 1) threads perform coalesced reads from global memory to fill a small local memory buffer
> 2) threads  perform lifting steps on this local buffer
> 3) local buffer is written back to global memory when complete.
>
> I am looking into changing to OpenCL 2d images instead of buffers. The advantages are :
>
> 1) automatic mirroring at boundaries
> 2) 2d spacial caching
> 3) RGB values can be stored and read together, and all RGB channels can be
> concurrently transformed using vector operations

Well, I haven't tried that, but you're welcome to to try your luck. I 
would suppose that this is not going to help much since, after all, the 
GPU has to perform exactly the same (or more) work than before. Anyhow, 
I would be interested in your findings.

> Caveat: with OpenCL 1.2, an image is either read or write, not read/write.
>
> Reading from images should be much faster than from global memory, because of caching. So, I would like to try getting rid of the local memory buffer, and perform a convolution instead. Is there a convolution that is equivalent to lifting for the 5/3 and 9/7 dwt transforms? Is this feasible, do you think?

Any wavelet filter is a convolution filter, thus there are of course 
equivalent convolution filters for the classical wavelets. The whole 
breakthrough of wavelets happened when lifting was invented because it 
was so easy to invert and because it was faster. Actually, it is a small 
pen and paper exercise to compute the convolution filter from the 
wavelet filter just by inserting the lifting steps into each other. It's 
probably easiest to do that in the Z-domain: Just write the lifting 
steps as multiplication of the Z-transform with the filter, then insert 
the output into each other and you get the final convolution.

I actually happen to have the convolution filter for the *synthesis* 
filters here, both for the low-pass and for the high-pass of the 5/3 and 
9/7:

static const FLOAT Low5_3Filter[]  = {  0.5f, 1.0f, 0.5f };
static const FLOAT High5_3Filter[] = { -0.125f, -0.25f,
                                        0.75f,
                                        -0.25f, -0.125f };
static const FLOAT Low9_7Filter[]  = { -0.091272f, -0.057544f,  0.591272f,
                                        1.115087f,
                                        0.591272f, -0.057544f, -0.091272f};
static const FLOAT High9_7Filter[] = {  0.026749f, 0.016864f, -0.078223f,
                                        -0.266864f, 0.602949f, -0.266864f,
                                        -0.078223f, 0.016864f,  0.026749f};

Since the filters are bi-orthogonal, creating from these convolution 
filters the analysis (compression) filters is simple, too. Just swap the 
filters and invert the signs of the odd filter steps. (This is because 
the polyphase matrix of the filters has determinant one, and the inverse 
of a det-1 matrix is just by swapping the diagonal elements and changing 
the signs of the off-diagonals).

HTHH,
	Thomas

[toc] | [prev] | [next] | [standalone]

#2473

Hi Thomas,
Thanks for your reply.

> > I am looking into changing to OpenCL 2d images instead of buffers. The advantages are :
> 
> >
> 
> > 1) automatic mirroring at boundaries
> 
> > 2) 2d spacial caching
> 
> > 3) RGB values can be stored and read together, and all RGB channels can be
> 
> > concurrently transformed using vector operations
> 
> 
> 
> Well, I haven't tried that, but you're welcome to to try your luck. I 
> 
> would suppose that this is not going to help much since, after all, the 
> 
> GPU has to perform exactly the same (or more) work than before. Anyhow, 
> 
> I would be interested in your findings.
> 
> 

Well, the GPU has silicon devoted to texture caching. It caches in 2d tiles,
so this should help 2D image filters like wavelet transform.  I am setting up 
a simple test application, so I should know fairly soon how well this works.
Certainly, the kernel will be much simpler: no worrying about boundaries, no
local memory buffer with bank conflicts, etc. Fewer bugs. I found a number 
of them in the gpudwt project.






> 
> > Caveat: with OpenCL 1.2, an image is either read or write, not read/write.
> 
> >
> 
> > Reading from images should be much faster than from global memory, because of caching. So, I would like to try getting rid of the local memory buffer, and perform a convolution instead. Is there a convolution that is equivalent to lifting for the 5/3 and 9/7 dwt transforms? Is this feasible, do you think?
> 
> 
> 
> Any wavelet filter is a convolution filter, thus there are of course 
> 
> equivalent convolution filters for the classical wavelets. The whole 
> 
> breakthrough of wavelets happened when lifting was invented because it 
> 
> was so easy to invert and because it was faster. Actually, it is a small 
> 
> pen and paper exercise to compute the convolution filter from the 
> 
> wavelet filter just by inserting the lifting steps into each other. It's 
> 
> probably easiest to do that in the Z-domain: Just write the lifting 
> 
> steps as multiplication of the Z-transform with the filter, then insert 
> 
> the output into each other and you get the final convolution.
> 
> 
> 
> I actually happen to have the convolution filter for the *synthesis* 
> 
> filters here, both for the low-pass and for the high-pass of the 5/3 and 
> 
> 9/7:
> 
> 
> 
> static const FLOAT Low5_3Filter[]  = {  0.5f, 1.0f, 0.5f };
> 
> static const FLOAT High5_3Filter[] = { -0.125f, -0.25f,
> 
>                                         0.75f,
> 
>                                         -0.25f, -0.125f };
> 
> static const FLOAT Low9_7Filter[]  = { -0.091272f, -0.057544f,  0.591272f,
> 
>                                         1.115087f,
> 
>                                         0.591272f, -0.057544f, -0.091272f};
> 
> static const FLOAT High9_7Filter[] = {  0.026749f, 0.016864f, -0.078223f,
> 
>                                         -0.266864f, 0.602949f, -0.266864f,
> 
>                                         -0.078223f, 0.016864f,  0.026749f};
> 

Thanks!

> 
> 
> Since the filters are bi-orthogonal, creating from these convolution 
> 
> filters the analysis (compression) filters is simple, too. Just swap the 
> 
> filters and invert the signs of the odd filter steps. (This is because 
> 
> the polyphase matrix of the filters has determinant one, and the inverse 
> 
> of a det-1 matrix is just by swapping the diagonal elements and changing 
> 
> the signs of the off-diagonals).
> 

I am curious: are there more conditions on the matrix to allow such a simple inversion? Any nxn matrix  A of non-zero determinant can be easily transformed into one with determinant 1 by dividing each element by det(A) ^ (1/n) .

Getting back to the lifting scheme with global/local buffers and windowing, do you mind if I ask you a few questions about your algorithm for the forward transform?  It seems to me that each window should be of dimension nxn, with workgroups of dimension (n/2 x 1) since odd and even points are transformed in separate passes, and since all columns are transformed first, followed by all rows.  But, in the Jiri Matela code, the windows are of size 8x196, for example.
This doesn't make sense to me, but I am surely missing something. 
Very interested in hearing your thoughts on this.

Thanks so much,
Aaron

[toc] | [prev] | [next] | [standalone]

#2493

Am 03.08.2014 03:01, schrieb Aaron Boxer:
> Hi Thomas,

>> Since the filters are bi-orthogonal, creating from these convolution
>>
>> filters the analysis (compression) filters is simple, too. Just swap the
>>
>> filters and invert the signs of the odd filter steps. (This is because
>>
>> the polyphase matrix of the filters has determinant one, and the inverse
>>
>> of a det-1 matrix is just by swapping the diagonal elements and changing
>>
>> the signs of the off-diagonals).
>>
>
> I am curious: are there more conditions on the matrix to allow such a simple inversion? Any nxn matrix  A of non-zero determinant can be easily transformed into one with determinant 1 by dividing each element by det(A) ^ (1/n) .

Ehem. We are talking about polyphase matrices, these are 2x2 matrices 
(in the case of wavelets, since we have two filters, high and lowpass) 
over the ring (the "ring" part is important, it is not a field!) of 
polynomials in z and z^{-1}. So yes, you can always compute an inverse 
by dividing the matrix elements by det(A)^{1/n}, except that the result 
will be in general an irrational function of Z and not a polynomial 
anymore, so it is no longer an element of the polynomial ring. A matrix 
in the polynomial ring Z over the reals is invertible if and only if the 
determinant is a monomial, i.e. contains only a single power of Z. (All 
this is actually a special case of a much more general theorem about 
units in rings). So in general, it does not help. If understood as a 
filter, a monomial in Z is just a scaling (due to the factor in front of 
the z) and a time shift (depending on the power of z). That is, while 
fields have always multiplicative inverses (except zero) and hence 
matrix inverses (except det() = 0) the same is not true for rings, and 
matrices over rings.

> Getting back to the lifting scheme with global/local buffers and windowing, do you mind if I ask you a few questions about your algorithm for the forward transform?  It seems to me that each window should be of dimension nxn, with workgroups of dimension (n/2 x 1) since odd and even points are transformed in separate passes, and since all columns are transformed first, followed by all rows.  But, in the Jiri Matela code, the windows are of size 8x196, for example.
> This doesn't make sense to me, but I am surely missing something.

Actually, my choice is almost, but not quite identical to Jiris. But it 
really depends on the GPU what works best, so I cannot give you a 
general recommendation. My algorithm is not exactly what Jiri does, and 
no, I do not have separate passes for high and low pass. Of course, 
there are lifting steps, but if you need to fire a GPU kernel more than 
once, you already lost because the Os overhead is so large. So there is 
one kernel that does a complete transformation.

Sorry, but I cannot get much more specific than this. If you want to buy 
the algorithm, you're surely welcome - I afraid it is not open source. 
It was quite some work that went into it, and I guess it's fair to ask 
for a compensation. (-:

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#2502

Hi Thomas,


> 
> > I am curious: are there more conditions on the matrix to allow such a simple inversion? Any nxn matrix  A of non-zero determinant can be easily transformed into one with determinant 1 by dividing each element by det(A) ^ (1/n) .
> 
> 
> 
> Ehem. We are talking about polyphase matrices, these are 2x2 matrices 
> 
> (in the case of wavelets, since we have two filters, high and lowpass) 
> 
> over the ring (the "ring" part is important, it is not a field!) of 
> 
> polynomials in z and z^{-1}. So yes, you can always compute an inverse 
> 
> by dividing the matrix elements by det(A)^{1/n}, except that the result 
> 
> will be in general an irrational function of Z and not a polynomial 
> 
> anymore, so it is no longer an element of the polynomial ring. A matrix 
> 
> in the polynomial ring Z over the reals is invertible if and only if the 
> 
> determinant is a monomial, i.e. contains only a single power of Z. (All 
> 
> this is actually a special case of a much more general theorem about 
> 
> units in rings). So in general, it does not help. If understood as a 
> 
> filter, a monomial in Z is just a scaling (due to the factor in front of 
> 
> the z) and a time shift (depending on the power of z). That is, while 
> 
> fields have always multiplicative inverses (except zero) and hence 
> 
> matrix inverses (except det() = 0) the same is not true for rings, and 
> 
> matrices over rings.
> 

Thanks. I guess I need to brush up on my ring theory :)


> 
> 
> > Getting back to the lifting scheme with global/local buffers and windowing, do you mind if I ask you a few questions about your algorithm for the forward transform?  It seems to me that each window should be of dimension nxn, with workgroups of dimension (n/2 x 1) since odd and even points are transformed in separate passes, and since all columns are transformed first, followed by all rows.  But, in the Jiri Matela code, the windows are of size 8x196, for example.
> 
> > This doesn't make sense to me, but I am surely missing something.
> 
> 
> 
> Actually, my choice is almost, but not quite identical to Jiris. But it 
> 
> really depends on the GPU what works best, so I cannot give you a 
> 
> general recommendation. My algorithm is not exactly what Jiri does, and 
> 
> no, I do not have separate passes for high and low pass. Of course, 
> 
> there are lifting steps, but if you need to fire a GPU kernel more than 
> 
> once, you already lost because the Os overhead is so large. So there is 
> 
> one kernel that does a complete transformation.
> 
> 

Thanks. I think I now understand why the window dimensions were chosen.
And yes, on windoze, the time it takes for an opencl call is very large!
As I am now focusing on encoding, it makes more sense to run this on Linux.


> 
> Sorry, but I cannot get much more specific than this. If you want to buy 
> 
> the algorithm, you're surely welcome - I afraid it is not open source. 
> 
> It was quite some work that went into it, and I guess it's fair to ask 
> 
> for a compensation. (-:
> 

Yes, I respect your expectation of a certain return on investment. 
Personally, I like the open model. But, it is taking an enormous amount of 
my time to develop this, and I haven't even gotten to the most challenging
part: the T1 encoder. 

Anyways, thanks again for all of your insights. They have been a real help.

Cheers,
Aaron

[toc] | [prev] | [next] | [standalone]

#2508

Hello Again,

> 
> Well, I haven't tried that, but you're welcome to to try your luck. I 
> 
> would suppose that this is not going to help much since, after all, the 
> 
> GPU has to perform exactly the same (or more) work than before. Anyhow, 
> 
> I would be interested in your findings.
> 


Well, my initial tests show that opencl images provide a definite advantage
over global memory, for 2D convolutions.  I am planning on re-writing my DWT
routine to :

0) pass compile time parameters in as constant kernel args
1) store RGB* data in opencl image (use RGB data for one frame plus single channel for another frame)
2) overlay PCIe data transfer with GPU kernel enqueue
3) use register for the vertical lifting, and local memory for horiztontal lifting
4) use 4-vector operations
5) simplify logic as much as possible to maximize register usage

I will post my results here when I get this working.

Cheers,
Aaron 

[toc] | [prev] | [next] | [standalone]

#2543

Well, to follow up on this thread, I now have a working version of both the 5/3 
and 9/7 forward dwt transforms.

Timing on windoze for a 4 megapixel RGBA image on my 2 year old, inexpensive AMD 7700 card:

7.8 ms for 5/3 forward, first resolution
10.7 ms for 9/7 forward, first resolution

Not bad. (I am ignoring time to move data between host and card, since this can
be pipelined)

The current crop of cards like the upcoming R9 285 should be several times faster.

For those who are curious, you can find the code here:

https://github.com/boxerab/roger

Cheers,
Aaron





On Tuesday, August 5, 2014 9:31:56 AM UTC-4, Aaron Boxer wrote:
> Hello Again,
> 
> 
> 
> > 
> 
> > Well, I haven't tried that, but you're welcome to to try your luck. I 
> 
> > 
> 
> > would suppose that this is not going to help much since, after all, the 
> 
> > 
> 
> > GPU has to perform exactly the same (or more) work than before. Anyhow, 
> 
> > 
> 
> > I would be interested in your findings.
> 
> > 
> 
> 
> 
> 
> 
> Well, my initial tests show that opencl images provide a definite advantage
> 
> over global memory, for 2D convolutions.  I am planning on re-writing my DWT
> 
> routine to :
> 
> 
> 
> 0) pass compile time parameters in as constant kernel args
> 
> 1) store RGB* data in opencl image (use RGB data for one frame plus single channel for another frame)
> 
> 2) overlay PCIe data transfer with GPU kernel enqueue
> 
> 3) use register for the vertical lifting, and local memory for horiztontal lifting
> 
> 4) use 4-vector operations
> 
> 5) simplify logic as much as possible to maximize register usage
> 
> 
> 
> I will post my results here when I get this working.
> 

[toc] | [prev] | [next] | [standalone]

#2576

Another update: I am beginning work on the bit plane coder for my jpeg 2000 codec, using the thesis "Design and Implementation of Arithmetic Coder for CUDA Platform" as my guide.

So far, the number look quite good: I estimate it will take roughly 200 ms
on my old HD 7700 to lossy encode a 16 MP RGBA image with single tile, 32x32 code blocks, and 5 levels of DWT. (I ignore time to move data between host and card). This translates into encoding 4K video at around 13 FPS.

The latest nVidia geforce 980 card has about 9x the perf of my 7700, and they have finally stepped up to the plate and fixed their opencl drivers
to get performance for luxmark sala opencl benchmark on par with radeon r290x, the latest AMD card.  So, this is really going to fly on these cards. And the new geforce 970 is a real bargain at USD $359. 

My code should be in alpha release by spring 2015.  And 2015 should bring the long awaited process shrink to 20 nm, with accompanied boost in gpu performance.  Can't wait.

Cheers,
Aaron






On Saturday, August 30, 2014 11:18:17 PM UTC-4, Aaron Boxer wrote:
> Well, to follow up on this thread, I now have a working version of both the 5/3 
> 
> and 9/7 forward dwt transforms.
> 
> 
> 
> Timing on windoze for a 4 megapixel RGBA image on my 2 year old, inexpensive AMD 7700 card:
> 
> 
> 
> 7.8 ms for 5/3 forward, first resolution
> 
> 10.7 ms for 9/7 forward, first resolution
> 
> 
> 
> Not bad. (I am ignoring time to move data between host and card, since this can
> 
> be pipelined)
> 
> 
> 
> The current crop of cards like the upcoming R9 285 should be several times faster.
> 
> 
> 
> For those who are curious, you can find the code here:
> 
> 
> 
> https://github.com/boxerab/roger
> 
> 
> 
> Cheers,
> 
> Aaron
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tuesday, August 5, 2014 9:31:56 AM UTC-4, Aaron Boxer wrote:
> 
> > Hello Again,
> 
> > 
> 
> > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Well, I haven't tried that, but you're welcome to to try your luck. I 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > would suppose that this is not going to help much since, after all, the 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > GPU has to perform exactly the same (or more) work than before. Anyhow, 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > I would be interested in your findings.
> 
> > 
> 
> > > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > Well, my initial tests show that opencl images provide a definite advantage
> 
> > 
> 
> > over global memory, for 2D convolutions.  I am planning on re-writing my DWT
> 
> > 
> 
> > routine to :
> 
> > 
> 
> > 
> 
> > 
> 
> > 0) pass compile time parameters in as constant kernel args
> 
> > 
> 
> > 1) store RGB* data in opencl image (use RGB data for one frame plus single channel for another frame)
> 
> > 
> 
> > 2) overlay PCIe data transfer with GPU kernel enqueue
> 
> > 
> 
> > 3) use register for the vertical lifting, and local memory for horiztontal lifting
> 
> > 
> 
> > 4) use 4-vector operations
> 
> > 
> 
> > 5) simplify logic as much as possible to maximize register usage
> 
> > 
> 
> > 
> 
> > 
> 
> > I will post my results here when I get this working.
> 
> >

[toc] | [prev] | [next] | [standalone]

#2330

Waiting for APU, both CPU and GPU reside and process the same memory.

On Friday, 16 May 2014 09:22:41 UTC+8, Aaron Boxer  wrote:
> Hello List, 
> 
> 
> 
> I am working on an open source DWT implementation written in OpenCL. 
> 
> It is a port of a CUDA project. 
> 
> 
> 
> https://github.com/OpenCodec/ocldwt 
> 
> 
> 
> The CUDA project handles 5,3 and 9,7 DWTs using the "lifting" technique. 
> 
> 
> 
> I need this for my other project, an OpenCL JPEG2000 library. 
> 
> 
> 
> I have finished the port for 5,3, but the library is not working properly. 
> 
> I see lines and strips of grey, but not a discernable dyadic decomposition of the image, as I would expect.  I am a signal processing neophyte, so sort of 
> 
> stuck right now. 
> 
> 
> 
> If any kind soul is interested in reviewing my code, trying to grok the algorithm being used, or anything, it would be greatly appreciated. 
> 
> 
> 
> Thanks, 
> 
> Aaron

[toc] | [prev] | [next] | [standalone]

#2331

On Wednesday, May 28, 2014 4:07:39 AM UTC-4, Fibonacci Code wrote:
> Waiting for APU, both CPU and GPU reside and process the same memory.
> 

Kaveri APU is here already:

http://www.anandtech.com/show/7677/amd-kaveri-review-a8-7600-a10-7850k





> 
> 
> On Friday, 16 May 2014 09:22:41 UTC+8, Aaron Boxer  wrote:
> 
> > Hello List, 
> 
> > 
> 
> > 
> 
> > 
> 
> > I am working on an open source DWT implementation written in OpenCL. 
> 
> > 
> 
> > It is a port of a CUDA project. 
> 
> > 
> 
> > 
> 
> > 
> 
> > https://github.com/OpenCodec/ocldwt 
> 
> > 
> 
> > 
> 
> > 
> 
> > The CUDA project handles 5,3 and 9,7 DWTs using the "lifting" technique. 
> 
> > 
> 
> > 
> 
> > 
> 
> > I need this for my other project, an OpenCL JPEG2000 library. 
> 
> > 
> 
> > 
> 
> > 
> 
> > I have finished the port for 5,3, but the library is not working properly. 
> 
> > 
> 
> > I see lines and strips of grey, but not a discernable dyadic decomposition of the image, as I would expect.  I am a signal processing neophyte, so sort of 
> 
> > 
> 
> > stuck right now. 
> 
> > 
> 
> > 
> 
> > 
> 
> > If any kind soul is interested in reviewing my code, trying to grok the algorithm being used, or anything, it would be greatly appreciated. 
> 
> > 
> 
> > 
> 
> > 
> 
> > Thanks, 
> 
> > 
> 
> > Aaron

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web