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.

Mesa, Wayland, X Will Get Some Summer Love

04-25-2011, 07:50 PM

Phoronix: Mesa, Wayland, X Will Get Some Summer Love

Google today has announced their 2011 student projects for the Google Summer of Code marathon. Four of the X.Org / Mesa / Wayland projects were accepted. Listed below are the accepted projects and a few notes...

Comment

VP8 and HLSL was removed probably due political reasons. As of VP8, I think somebody else (maybe even Google) will write OpenCL code to accelerate this and integrate it into libvp8. This way it will work well both on multicore CPU and even moderatly-modern GPUs well, under all operating system with OpenCL support. VP8 docoding using GLSL would be even better (as it is supported on wider number of devices and drivers) probably but slightly harder from developer point of view. So nothing to be worried about, we will see hardware accelerated VP8 soon.

Comment

VP8 and HLSL was removed probably due political reasons. As of VP8, I think somebody else (maybe even Google) will write OpenCL code to accelerate this and integrate it into libvp8. This way it will work well both on multicore CPU and even moderatly-modern GPUs well, under all operating system with OpenCL support. VP8 docoding using GLSL would be even better (as it is supported on wider number of devices and drivers) probably but slightly harder from developer point of view. So nothing to be worried about, we will see hardware accelerated VP8 soon.

Also using the open source drivers? Even if the OpenCL state tracker-project finishes successfully, I doubt it will be as fast as the fglrx-implementation, and so, maybe not fast enough to accelerate decoding.

Acceleration via GLSL does sound interesting. But I presume the open source driver isn't as fast at GLSL as fglrx either? I presume that's - in part - why a state tracker implementing the acceleration directly in TGSI has been proposed. There has been a lot of work done on GLSL decoding acceleration from XBMC though, so there should be a good code base to start from.

But I'm not holding my breath. It just seems that this [GPU accelerated video decoding] is harder than what it appears to be.

Comment

VP8 and HLSL was removed probably due political reasons. As of VP8, I think somebody else (maybe even Google) will write OpenCL code to accelerate this and integrate it into libvp8. This way it will work well both on multicore CPU and even moderatly-modern GPUs well, under all operating system with OpenCL support. VP8 docoding using GLSL would be even better (as it is supported on wider number of devices and drivers) probably but slightly harder from developer point of view. So nothing to be worried about, we will see hardware accelerated VP8 soon.

Entirely wrong; the chosen proposals were chosen based on their relative quality, and only four mentors were available, so only four proposals were chosen. Odds are good that, if we had had a fifth mentor, the VP8 Gallium project would have been chosen as well, but it was a bit ambitious for GSoC.

Hopefully, all of the projects which were not chosen for GSoC will reapply for EVoC instead.

It sounds like a good project, but I'd also be willing to work with him on the VP8 OpenCL port (not mentor/mentee necessarily, just working together). If the OpenCL Gallium state tracker gets finished, there's no real need to get a VP8/Gallium state tracker up and running. We should be able to extract the needed performance out of the OpenCL version without having to translate it to a state tracker. And then the BSD/Solaris/etc. people can benefit from the work as well.