Mesa, Wayland, X Will Get Some Summer Love

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

http://www.phoronix.com/vr.php?view=OTM3Nw

All those who were left out should apply for the X.Org Endless Vacation of Code initiative.

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.

Quote:

---

Originally Posted by baryluk

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.

Any plans to stop using the "foobar will get some love" snowclone? It wasn't really that funny in the first place and now it's really annoying.

Quote:

---

Originally Posted by baryluk

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.

I'm impatient to see how the epic "OpenCL Gallium3D State Tracker" will turn out. Hope that phoronyx will keep us informed.

according to the submitter.

http://lists.freedesktop.org/archive...il/007055.html

I hope he does look into the EVoC, it sounded like a good project.

Quote:

---

Originally Posted by smitty3268

according to the submitter.

http://lists.freedesktop.org/archive...il/007055.html

I hope he does look into the EVoC, it sounded like a good project.

---

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.

Quote:

---

Originally Posted by Veerappan

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

---

didn't you just did/completed this a few weeks back??? :confused: