If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I was very glad to see this work get merged into Piglit last week. If i've got any free time at home, I'll be writing up enough tests to hopefully get the OpenCL version of the WebM/VP8 decoder library working on clover (it was segfaulting as of 2 weeks ago, but Tom Stellard also just merged multiple-kernel per file support into mesa so who knows...).

Comment

I was very glad to see this work get merged into Piglit last week. If i've got any free time at home, I'll be writing up enough tests to hopefully get the OpenCL version of the WebM/VP8 decoder library working on clover (it was segfaulting as of 2 weeks ago, but Tom Stellard also just merged multiple-kernel per file support into mesa so who knows...).

Do you know (or give an estimate) how your decoder would compare against a shader based implementation?? Konig mentioned in this thread that h264 didn't work out that well.

Comment

I was very glad to see this work get merged into Piglit last week. If i've got any free time at home, I'll be writing up enough tests to hopefully get the OpenCL version of the WebM/VP8 decoder library working on clover (it was segfaulting as of 2 weeks ago, but Tom Stellard also just merged multiple-kernel per file support into mesa so who knows...).

Those patches were reviewed on the list, but I haven't had a chance to merge them yet.

Lately, I've been working with the GEGL (www.gegl.org) image processing library, and trying to get some it's OpenCL based operations to work with the Open Source driver. I was able to get the gaussian blur working last week, and in the process, I made significant improvements to the compute code. I'm still working on cleaning up the changes and getting them reviewed, but I've pushed all my outstanding patches to the Sep24-Compute branch of my fdo repo (http://cgit.freedesktop.org/~tstellar/mesa) in case anyone wants to test them out.

Comment

Do you know (or give an estimate) how your decoder would compare against a shader based implementation?? Konig mentioned in this thread that h264 didn't work out that well.

I'm going to guess: poorly. At least compared to CPU-only. I'm not sure how well/poorly the h.264 shader-based implementation performed.

Currently, the CL-based decoder only does loop filtering on the GPU, which means there's a lot of PCI-e traffic/latency to copy the frame data back and forth between system/gpu memory. I've written code to do subpixel filtering/dequantization/idct in CL kernels, but it's not fully optimized, and it has also suffered some bit rot over time (I first wrote that code in Jan 2011). Once the clover/r600+llvm code gets to the point that I can run the WebM CL decoder on Mesa+r600 without errors, then I'll try to rebase things against the current upstream WebM repository and re-write the subpixel filtering, dequant, and IDCT code. If I can get all of those working and completed, the decode should at least get closer to reaching performance parity with the CPU-only decoder (currently around 1/2 speed). If I can introduce a codepath that doesn't require copying the data back from the CPU (just provide a buffer handle in YUV format to the compositor), then performance could end up as a net gain.

Currently, the error that I'm running into is that clover discards the build options arguments when compiling kernels. I've submitted a piglit CL test, but it hasn't been reviewed/committed yet.