[Mesa3d-dev] Google Summer of Code: we got in / call for mentors!
Hi, Good news, X.Org just got accepted into the Google Summer of Code program! Now we need mentors. If you are a developer and would like to possibly mentor Summer of Code projects, please contact me off-list. Thanks, Stephane -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
Yes, I stumbled across Rudd's project for XMBC as well. Unfortunetely he has been inactive since last year and I cannot find much information on how far he got with it. I will try and disrupt his hibernation at XMBC's forum. Thanks for the tips! On Fri, Jun 19, 2009 at 8:42 PM, Younes Mantonyoune...@gmail.com wrote: On Fri, Jun 19, 2009 at 11:39 AM, Kaspar Bumkekaspar.bu...@gmail.com wrote: Yeah that was me on your blog. Thanks for answering here. I found your work very interesting and would like to continue where you left of. I do not have alot of experience, but I can make up for it with available time (a year!) and enthusiasm. I am going to start looking into OpenGL first of all and using and developing Mesa3D in general. It will probably be a long time before I will be able to use anything you would be pushing at this point. I'd suggest playing around in OpenGL too. If you can put together a proof of concept demo or something that did one of the decoding stages (e.g. H264 mocomp) it wouldn't be too hard to port to Gallium. IIRC there was somebody in GSoC with XBMC last year who attempted H264. I don't know how far he got but you could pick up where he left off or use his work as a reference. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
Yeah that was me on your blog. Thanks for answering here. I found your work very interesting and would like to continue where you left of. I do not have alot of experience, but I can make up for it with available time (a year!) and enthusiasm. I am going to start looking into OpenGL first of all and using and developing Mesa3D in general. It will probably be a long time before I will be able to use anything you would be pushing at this point. On Mon, Jun 15, 2009 at 11:10 PM, Younes Mantonyoune...@gmail.com wrote: On Mon, Jun 15, 2009 at 11:59 AM, kasbahkaspar.bu...@gmail.com wrote: Corbin Simpson wrote: we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. Has anything happend with this? Are you doing it for GSoC Denis? I am interested in getting involved in this for my final year undergraduate project. So has anyone begun attempting to beef up g3dvl to decode h.264 ? Nobody is doing this for GSoC as far as I know. (Did you ask the same thing on my blog? Sorry, I meant to respond to you there.) As far as beefing up g3dvl for this I started doing things to at least make it feasible to implement VDPAU and other APIs in a clean way, and I still hack away at it whenever I get a bit of time (hopefully more time now that a few of my other obligations have wrapped up). If you want to do stuff in this area I guess it would inspire me to move a little faster and push what I have so far. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Fri, Jun 19, 2009 at 11:39 AM, Kaspar Bumkekaspar.bu...@gmail.com wrote: Yeah that was me on your blog. Thanks for answering here. I found your work very interesting and would like to continue where you left of. I do not have alot of experience, but I can make up for it with available time (a year!) and enthusiasm. I am going to start looking into OpenGL first of all and using and developing Mesa3D in general. It will probably be a long time before I will be able to use anything you would be pushing at this point. I'd suggest playing around in OpenGL too. If you can put together a proof of concept demo or something that did one of the decoding stages (e.g. H264 mocomp) it wouldn't be too hard to port to Gallium. IIRC there was somebody in GSoC with XBMC last year who attempted H264. I don't know how far he got but you could pick up where he left off or use his work as a reference. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
Corbin Simpson wrote: we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. Has anything happend with this? Are you doing it for GSoC Denis? I am interested in getting involved in this for my final year undergraduate project. So has anyone begun attempting to beef up g3dvl to decode h.264 ? -- View this message in context: http://www.nabble.com/Google-Summer-of-Code-tp22937144p24037448.html Sent from the mesa3d-dev mailing list archive at Nabble.com. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Mon, Jun 15, 2009 at 11:59 AM, kasbahkaspar.bu...@gmail.com wrote: Corbin Simpson wrote: we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. Has anything happend with this? Are you doing it for GSoC Denis? I am interested in getting involved in this for my final year undergraduate project. So has anyone begun attempting to beef up g3dvl to decode h.264 ? Nobody is doing this for GSoC as far as I know. (Did you ask the same thing on my blog? Sorry, I meant to respond to you there.) As far as beefing up g3dvl for this I started doing things to at least make it feasible to implement VDPAU and other APIs in a clean way, and I still hack away at it whenever I get a bit of time (hopefully more time now that a few of my other obligations have wrapped up). If you want to do stuff in this area I guess it would inspire me to move a little faster and push what I have so far. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Thu, Apr 9, 2009 at 04:09, Roland Scheidegger srol...@vmware.com wrote: On 08.04.2009 22:45, Stephane Marchesin wrote: On Wed, Apr 8, 2009 at 21:43, Corbin Simpson mostawesomed...@gmail.com wrote: Brian Paul wrote: Denis Martinez wrote: Hi! I'm a GSoC student interested in the Gallium subjects which are about the implementation of VDPAU and OpenGL 3.0. I would like to start learning Gallium3D, so my question is: Do you have any useful learning resources to recommend as a starting point? Also I'm thinking about hacking on Gallium, something not too difficult, in order to get started. I'm already familiar with C, Xorg, git, compiling/installing, but still have a lot to learn about OpenGL. Hi Denis, I'm not too familiar with the VDPAU stuff so maybe someone else can comment on that. marcheu, ymanton, and I were talking about this a bit ago. Essentially, we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. Yes, as Corbin said, the plan is two-fold: - first, bring g3dvl up to h.264 levels. Some things are small and can be adapted from MPEG2 (new quantifying schemes and new block sizes for motion vectors, new idct...) and some others are bigger (supporting multiple reference frames, CABAC decoding, but that one has to be done on the CPU anyway, unless you come up with a genius idea to do it on the GPU). I would say you simply have to go one feature at a time until you get mostly complete h.264 (let's be honest here - no one implements the full h.264 standard today, heck 16 reference frames of 1080p is using up 64Mb of vram in YV12 format already so not all cards can !). - then add support for an API that actually exposes that new functionality. VDPAU is probably our best candidate (short of creating our own API, which is a no-no for standardization reasons). What about VAAPI? XvBA? - VAAPI has multiple explicit entry stages, which is more complicated to do properly (you can't just have a single entry point for the data in your code with it, you have to implement them all aven if you know they're not going to be useful). That's because it was primarily designed with embedded systems in mind which I think is a mistake (in a year most of those embedded systems will be able to do full H.264 in hw). - XvBA is going to be the loser anyway, it has seen no player adoption so far. - On the other hand, VDPAU has a single entry point to which you just feed the data. So you're free to do what you like in between. Furthermore most players already have support for it in mainline. So all in all, as we can't pursue the implementation of 1000 APIs, and for simplicity's sake, VDPAU is the winner here IMO. Stephane -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
2009/4/9 Zou, Nanhai nanhai@intel.com: Hi, What kind of GPU shading language are you using for mc and idct? What do you mean GPU shading language ? It generates gallium shaders, just look at the g3dvl state tracker it's all there. Stephane -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
-Original Message- From: stephane.marche...@gmail.com [mailto:stephane.marche...@gmail.com] On Behalf Of Stephane Marchesin Sent: 2009年4月9日 14:32 To: Zou, Nanhai Cc: Corbin Simpson; Denis Martinez; mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Google Summer of Code 2009/4/9 Zou, Nanhai nanhai@intel.com: Hi, What kind of GPU shading language are you using for mc and idct? What do you mean GPU shading language ? It generates gallium shaders, just look at the g3dvl state tracker it's all there. I have not been looking into gallium support yet. Are you working on software fallback or on some real hardware? I am now working on HW accelerated media support for our chip(XVMC etc), next plan is to support VAAPI. The code is now in our 2D dirver, in freedesktop.org xf86-video-driver . The master branch has MC only implement, There is a branch xvmc-vld which support offload mpeg2 decode to GPU from VLD entry. Media kernels running on GPU will do MC and IDCT and IQ, fix function unit HW will do VLD decode. I think merge the VAAPI support into mesa might be a good idea. However currently we program media kernel with very low level assembly code. I fell it is better we can have some higher level shading language for later complex H.264 support and video post processing. But I don't think GLSL like language can generate efficient enough media processing code. So I am wondering which kind of programming language are you using for GPU media decoding. Thanks Zou Nan hai Stephane -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai nanhai@intel.com wrote: I have not been looking into gallium support yet. Are you working on software fallback or on some real hardware? We have xvmc on top of g3dvl working on nv40-class hardware (and more generically, it should work any card which has a gallium driver). We've had this since last year's summer of code. Our main purpose is to avoid reinventing the wheel with each driver... I am now working on HW accelerated media support for our chip(XVMC etc), next plan is to support VAAPI. The code is now in our 2D dirver, in freedesktop.org xf86-video-driver . The master branch has MC only implement, There is a branch xvmc-vld which support offload mpeg2 decode to GPU from VLD entry. Media kernels running on GPU will do MC and IDCT and IQ, fix function unit HW will do VLD decode. Well, we don't have hw video decoding specs for nvidia/ati (and on some hardware we don't even have any video decoding hw), so we use the shaders for everything anyway. As far as VAAPI goes, someone could add a lib for it on top of g3dvl, that's probably the nicest solution. But as I said in the other email, the number of VAAPI entry points makes it difficult to implement. In reality we don't need all these entry points, only old/embedded hardware needs them, and that type of hardware has no gallium support anyway. I think merge the VAAPI support into mesa might be a good idea. If you don't have gallium for your chip, you have a specific implementation then? In which case it doesn't make much sense to merge it into mesa... However currently we program media kernel with very low level assembly code. I fell it is better we can have some higher level shading language for later complex H.264 support and video post processing. But I don't think GLSL like language can generate efficient enough media processing code. So I am wondering which kind of programming language are you using for GPU media decoding. Well we already use a GLSL-like language for that (intermediate gallium representation) and we already have a working xvmc implementation, so I don't think these concerns hold. Stephane -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
-Original Message- From: stephane.marche...@gmail.com [mailto:stephane.marche...@gmail.com] On Behalf Of Stephane Marchesin Sent: 2009年4月9日 15:20 To: Zou, Nanhai Cc: Corbin Simpson; Denis Martinez; mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Google Summer of Code On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai nanhai@intel.com wrote: I have not been looking into gallium support yet. Are you working on software fallback or on some real hardware? We have xvmc on top of g3dvl working on nv40-class hardware (and more generically, it should work any card which has a gallium driver). We've had this since last year's summer of code. Our main purpose is to avoid reinventing the wheel with each driver... I am now working on HW accelerated media support for our chip(XVMC etc), next plan is to support VAAPI. The code is now in our 2D dirver, in freedesktop.org xf86-video-driver . The master branch has MC only implement, There is a branch xvmc-vld which support offload mpeg2 decode to GPU from VLD entry. Media kernels running on GPU will do MC and IDCT and IQ, fix function unit HW will do VLD decode. Well, we don't have hw video decoding specs for nvidia/ati (and on some hardware we don't even have any video decoding hw), so we use the shaders for everything anyway. As far as VAAPI goes, someone could add a lib for it on top of g3dvl, that's probably the nicest solution. But as I said in the other email, the number of VAAPI entry points makes it difficult to implement. In reality we don't need all these entry points, only old/embedded hardware needs them, and that type of hardware has no gallium support anyway. You can choose to implement 1 single entry point e.g. VLD. What I think VAAPI is missing is post processing,However I can talk to VAAPI people to improve the API, anyway VAAPI is only at version 0.30. I think merge the VAAPI support into mesa might be a good idea. If you don't have gallium for your chip, you have a specific implementation then? In which case it doesn't make much sense to merge it into mesa... Our current XVMC-vld implementation is in the 2D driver. I am planning to implement to support VAAPI in a stand alone liberary. However I am thinking implement VAAPI in mesa may help us to have less duplicated code, That means support for dri stuff, rendering, multi stream blending , scaling, subpicture easier. However currently we program media kernel with very low level assembly code. I fell it is better we can have some higher level shading language for later complex H.264 support and video post processing. But I don't think GLSL like language can generate efficient enough media processing code. So I am wondering which kind of programming language are you using for GPU media decoding. Well we already use a GLSL-like language for that (intermediate gallium representation) and we already have a working xvmc implementation, so I don't think these concerns hold. Does the XVMC implementation support MC only flag or MC + IDCT? Is it efficient enough to decode high rate HD content? Is it a high level language or you mean you do MC and IDCT with mesa internal op? I think a high level language is most useful for performance tuning and debuging, consider the complexity of H.264 and post processing. I have considered using GLSL, but for our media pipeline, hardware usually run instruction in 16 ways or wider. So if the language can provide data element like vec16 or even vec32 vec64 that would be nice. Thanks Zou Nan hai Stephane -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
Zou, Nanhai wrote: -Original Message- From: stephane.marche...@gmail.com [mailto:stephane.marche...@gmail.com] On Behalf Of Stephane Marchesin Sent: 2009年4月9日 15:20 To: Zou, Nanhai Cc: Corbin Simpson; Denis Martinez; mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Google Summer of Code On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai nanhai@intel.com wrote: I have not been looking into gallium support yet. Are you working on software fallback or on some real hardware? We have xvmc on top of g3dvl working on nv40-class hardware (and more generically, it should work any card which has a gallium driver). We've had this since last year's summer of code. Our main purpose is to avoid reinventing the wheel with each driver... I am now working on HW accelerated media support for our chip(XVMC etc), next plan is to support VAAPI. The code is now in our 2D dirver, in freedesktop.org xf86-video-driver . The master branch has MC only implement, There is a branch xvmc-vld which support offload mpeg2 decode to GPU from VLD entry. Media kernels running on GPU will do MC and IDCT and IQ, fix function unit HW will do VLD decode. Well, we don't have hw video decoding specs for nvidia/ati (and on some hardware we don't even have any video decoding hw), so we use the shaders for everything anyway. As far as VAAPI goes, someone could add a lib for it on top of g3dvl, that's probably the nicest solution. But as I said in the other email, the number of VAAPI entry points makes it difficult to implement. In reality we don't need all these entry points, only old/embedded hardware needs them, and that type of hardware has no gallium support anyway. You can choose to implement 1 single entry point e.g. VLD. What I think VAAPI is missing is post processing,However I can talk to VAAPI people to improve the API, anyway VAAPI is only at version 0.30. VAAPI is currently unplanned, which IME typically translates to patches welcome. Ditto for XvBA. :3 In all honesty, VDPAU is simple, straightforward, and (for once) we're in a position where implementing the nVidia screw-the-standards-let's-write-our-own-standard system actually is possible and full of win, so that's our first target. (Oh, and embedded hardware support could always be added. Gallium pipes for NEON, anybody?) I think merge the VAAPI support into mesa might be a good idea. If you don't have gallium for your chip, you have a specific implementation then? In which case it doesn't make much sense to merge it into mesa... Our current XVMC-vld implementation is in the 2D driver. I am planning to implement to support VAAPI in a stand alone liberary. However I am thinking implement VAAPI in mesa may help us to have less duplicated code, That means support for dri stuff, rendering, multi stream blending , scaling, subpicture easier. Well, Gallium code's generic, so it does lead to less duplication. Rather than write Intel-specific code, you write Gallium code which all drivers can use, and then beef up the Intel drivers to be able to handle it. However currently we program media kernel with very low level assembly code. I fell it is better we can have some higher level shading language for later complex H.264 support and video post processing. But I don't think GLSL like language can generate efficient enough media processing code. So I am wondering which kind of programming language are you using for GPU media decoding. Well we already use a GLSL-like language for that (intermediate gallium representation) and we already have a working xvmc implementation, so I don't think these concerns hold. Does the XVMC implementation support MC only flag or MC + IDCT? Is it efficient enough to decode high rate HD content? Yes, yes. Is it a high level language or you mean you do MC and IDCT with mesa internal op? I think a high level language is most useful for performance tuning and debuging, consider the complexity of H.264 and post processing. I have considered using GLSL, but for our media pipeline, hardware usually run instruction in 16 ways or wider. So if the language can provide data element like vec16 or even vec32 vec64 that would be nice. The internal representation used in Gallium is TGSI and it should be sufficient for nearly all your needs. Check out http://www.tungstengraphics.co/wiki/files/tgsi.pdf for the formal specification, or if you'd like more concrete examples, look at src/gallium/auxiliary/tgsi for Gallium's TGSI utilities, or most of the drivers in src/gallium/drivers/* for card-specific TGSI decoders. ~ C. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list
Re: [Mesa3d-dev] Google Summer of Code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephane Marchesin wrote: That's my point: video codecs move too fast to be put into silicon, and require too many resources to implement. So we should use shaders and lay everything onto an API that takes care of the hardware details. This is one case where I agree with keithp about fixed-function hardware. You can always make a fixed-function video decoder that uses orders of magnitude less power than a programmable decoder. How many movies do you want to be able to watch on that long flight from LA to Sydney? As a fairly extreme example, the CPU in the iPod can decode MP3. However, doing it on the CPU, even that power efficient CPU, uses more that 5x the power of doing on the dedicated MP3 decode hardware. I don't know that the difference is as extreme for video decode hardware, but even 2x would pretty significant. I guess the point is that fixed-function decode hardware won't disappear, at least not on mobile devices, any time soon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkneOGgACgkQX1gOwKyEAw8SugCeMn6PY26FccQAxlM15vHY1ZME Sd4Anj1ZGDRI+lXP/5q08w85eAbFgXqB =z0tz -END PGP SIGNATURE- -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Thu, Apr 9, 2009 at 20:03, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephane Marchesin wrote: That's my point: video codecs move too fast to be put into silicon, and require too many resources to implement. So we should use shaders and lay everything onto an API that takes care of the hardware details. This is one case where I agree with keithp about fixed-function hardware. You can always make a fixed-function video decoder that uses orders of magnitude less power than a programmable decoder. How many movies do you want to be able to watch on that long flight from LA to Sydney? It depends, lets say my movie is H264 and I have an i945. Since that card can't do H264 decoding as fixed pipe and since the driver has no shader-based H264, I end up using the CPU and actually a lot more battery. It's actually way worse than fixed hardware. I end up running out of battery in the taxi to the airport. On the other hand, had I used a shader-based video decoding library, I could at least accelerate most of the decoding. That would probably let me watch movies at least until I land in Hong kong (where I catch the connecting flight). Really H264 (or any codec for that matter) is not the end of the tunnel. Hey, no fixed pipe hardware implements the full H264 spec today. What's going to happen when newer videos start using the full range of capabilities? Yes, fallback to CPU rendering again. Or corrupt video. As a fairly extreme example, the CPU in the iPod can decode MP3. However, doing it on the CPU, even that power efficient CPU, uses more that 5x the power of doing on the dedicated MP3 decode hardware. I don't know that the difference is as extreme for video decode hardware, but even 2x would pretty significant. I guess the point is that fixed-function decode hardware won't disappear, at least not on mobile devices, any time soon. Yeah, the answer for those is pretty simple IMO: we just don't support these. And we can handle the rest with g3dvl. Stephane -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Thursday 09 April 2009 14:03:20 Ian Romanick wrote: Stephane Marchesin wrote: That's my point: video codecs move too fast to be put into silicon, and require too many resources to implement. So we should use shaders and lay everything onto an API that takes care of the hardware details. This is one case where I agree with keithp about fixed-function hardware. You can always make a fixed-function video decoder that uses orders of magnitude less power than a programmable decoder. How many movies do you want to be able to watch on that long flight from LA to Sydney? As a fairly extreme example, the CPU in the iPod can decode MP3. However, doing it on the CPU, even that power efficient CPU, uses more that 5x the power of doing on the dedicated MP3 decode hardware. I don't know that the difference is as extreme for video decode hardware, but even 2x would pretty significant. I guess the point is that fixed-function decode hardware won't disappear, at least not on mobile devices, any time soon. This isn't a problem for Gallium. As previously discussed the parts of the video pipeline that do appear as fixed-function in gpus would be exported to a gallium video interface. The default implementation of the interface would be using TGSI and Gallium interface (so 3D pipeline) but if particular hardware supported those features the driver could just implement the video interface using the fixed-function parts. z -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Thu, Apr 9, 2009 at 20:22, Zack Rusin za...@vmware.com wrote: On Thursday 09 April 2009 14:03:20 Ian Romanick wrote: Stephane Marchesin wrote: That's my point: video codecs move too fast to be put into silicon, and require too many resources to implement. So we should use shaders and lay everything onto an API that takes care of the hardware details. This is one case where I agree with keithp about fixed-function hardware. You can always make a fixed-function video decoder that uses orders of magnitude less power than a programmable decoder. How many movies do you want to be able to watch on that long flight from LA to Sydney? As a fairly extreme example, the CPU in the iPod can decode MP3. However, doing it on the CPU, even that power efficient CPU, uses more that 5x the power of doing on the dedicated MP3 decode hardware. I don't know that the difference is as extreme for video decode hardware, but even 2x would pretty significant. I guess the point is that fixed-function decode hardware won't disappear, at least not on mobile devices, any time soon. This isn't a problem for Gallium. As previously discussed the parts of the video pipeline that do appear as fixed-function in gpus would be exported to a gallium video interface. The default implementation of the interface would be using TGSI and Gallium interface (so 3D pipeline) but if particular hardware supported those features the driver could just implement the video interface using the fixed-function parts. It could become very hairy then. Interfacing arbitrary shader-based/fixed pipeline bits could prove to be a difficult challenge, especially since there is no standard format for data between the decoding stages (memory layout, bits...). You could put that burden onto the driver but that complicates things quite a bit. Again, as I see it, it's increasingly difficult to follow the video codec trend and fixed pipe didn't cut it before. For example on most cards we have had H262 fixed pipe for years, and H263 (divx) movies were never accelerated by those fixed pipe cards until H264 came out a lot later. H263 was probably the most widespread format of video these days though, and we completely missed it. Stephane -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
Denis Martinez wrote: Hi! I'm a GSoC student interested in the Gallium subjects which are about the implementation of VDPAU and OpenGL 3.0. I would like to start learning Gallium3D, so my question is: Do you have any useful learning resources to recommend as a starting point? Also I'm thinking about hacking on Gallium, something not too difficult, in order to get started. I'm already familiar with C, Xorg, git, compiling/installing, but still have a lot to learn about OpenGL. Hi Denis, I'm not too familiar with the VDPAU stuff so maybe someone else can comment on that. If you want to learn about Gallium, you should first check out the wiki page at http://www.tungstengraphics.com/wiki/index.php/Gallium3D It's a little out of date, but the concepts are still correct. I'll try to freshen it up a little one of these days/evenings. If you'd like to get your hands dirty in the Mesa/Gallium code, I could probably suggest a few things. For example, we don't currently support the GL_ARB_framebuffer_object extension. The EXT version is supported. The main difference (and the reason the ARB version is not supported) is that the ARB versions allows your color buffers, depth buffers and stencil buffers to be of different sizes. It might a simple matter to test/fix the mis-matched framebuffer size issues. Otherwise, if you grep the code for XXX or to-do comments you'll probably find some areas where help is needed. Unfortunately for beginnners, all the easy stuff in Mesa/Gallium was done long ago. Most people find an area of particular interest and dig into it. Feel free to ask questions here. -Brian -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
Brian Paul wrote: Denis Martinez wrote: Hi! I'm a GSoC student interested in the Gallium subjects which are about the implementation of VDPAU and OpenGL 3.0. I would like to start learning Gallium3D, so my question is: Do you have any useful learning resources to recommend as a starting point? Also I'm thinking about hacking on Gallium, something not too difficult, in order to get started. I'm already familiar with C, Xorg, git, compiling/installing, but still have a lot to learn about OpenGL. Hi Denis, I'm not too familiar with the VDPAU stuff so maybe someone else can comment on that. marcheu, ymanton, and I were talking about this a bit ago. Essentially, we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. ~ C. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Wed, Apr 8, 2009 at 21:43, Corbin Simpson mostawesomed...@gmail.com wrote: Brian Paul wrote: Denis Martinez wrote: Hi! I'm a GSoC student interested in the Gallium subjects which are about the implementation of VDPAU and OpenGL 3.0. I would like to start learning Gallium3D, so my question is: Do you have any useful learning resources to recommend as a starting point? Also I'm thinking about hacking on Gallium, something not too difficult, in order to get started. I'm already familiar with C, Xorg, git, compiling/installing, but still have a lot to learn about OpenGL. Hi Denis, I'm not too familiar with the VDPAU stuff so maybe someone else can comment on that. marcheu, ymanton, and I were talking about this a bit ago. Essentially, we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. Yes, as Corbin said, the plan is two-fold: - first, bring g3dvl up to h.264 levels. Some things are small and can be adapted from MPEG2 (new quantifying schemes and new block sizes for motion vectors, new idct...) and some others are bigger (supporting multiple reference frames, CABAC decoding, but that one has to be done on the CPU anyway, unless you come up with a genius idea to do it on the GPU). I would say you simply have to go one feature at a time until you get mostly complete h.264 (let's be honest here - no one implements the full h.264 standard today, heck 16 reference frames of 1080p is using up 64Mb of vram in YV12 format already so not all cards can !). - then add support for an API that actually exposes that new functionality. VDPAU is probably our best candidate (short of creating our own API, which is a no-no for standardization reasons). Stephane -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On 08.04.2009 22:45, Stephane Marchesin wrote: On Wed, Apr 8, 2009 at 21:43, Corbin Simpson mostawesomed...@gmail.com wrote: Brian Paul wrote: Denis Martinez wrote: Hi! I'm a GSoC student interested in the Gallium subjects which are about the implementation of VDPAU and OpenGL 3.0. I would like to start learning Gallium3D, so my question is: Do you have any useful learning resources to recommend as a starting point? Also I'm thinking about hacking on Gallium, something not too difficult, in order to get started. I'm already familiar with C, Xorg, git, compiling/installing, but still have a lot to learn about OpenGL. Hi Denis, I'm not too familiar with the VDPAU stuff so maybe someone else can comment on that. marcheu, ymanton, and I were talking about this a bit ago. Essentially, we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. Yes, as Corbin said, the plan is two-fold: - first, bring g3dvl up to h.264 levels. Some things are small and can be adapted from MPEG2 (new quantifying schemes and new block sizes for motion vectors, new idct...) and some others are bigger (supporting multiple reference frames, CABAC decoding, but that one has to be done on the CPU anyway, unless you come up with a genius idea to do it on the GPU). I would say you simply have to go one feature at a time until you get mostly complete h.264 (let's be honest here - no one implements the full h.264 standard today, heck 16 reference frames of 1080p is using up 64Mb of vram in YV12 format already so not all cards can !). - then add support for an API that actually exposes that new functionality. VDPAU is probably our best candidate (short of creating our own API, which is a no-no for standardization reasons). What about VAAPI? XvBA? Roland -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
-Original Message- From: Stephane Marchesin [mailto:marche...@icps.u-strasbg.fr] Sent: 2009年4月9日 4:46 To: Corbin Simpson Cc: Denis Martinez; mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Google Summer of Code On Wed, Apr 8, 2009 at 21:43, Corbin Simpson mostawesomed...@gmail.com wrote: Brian Paul wrote: Denis Martinez wrote: Hi! I'm a GSoC student interested in the Gallium subjects which are about the implementation of VDPAU and OpenGL 3.0. I would like to start learning Gallium3D, so my question is: Do you have any useful learning resources to recommend as a starting point? Also I'm thinking about hacking on Gallium, something not too difficult, in order to get started. I'm already familiar with C, Xorg, git, compiling/installing, but still have a lot to learn about OpenGL. Hi Denis, I'm not too familiar with the VDPAU stuff so maybe someone else can comment on that. marcheu, ymanton, and I were talking about this a bit ago. Essentially, we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. Yes, as Corbin said, the plan is two-fold: - first, bring g3dvl up to h.264 levels. Some things are small and can be adapted from MPEG2 (new quantifying schemes and new block sizes for motion vectors, new idct...) and some others are bigger (supporting multiple reference frames, CABAC decoding, but that one has to be done on the CPU anyway, unless you come up with a genius idea to do it on the GPU). I would say you simply have to go one feature at a time until you get mostly complete h.264 (let's be honest here - no one implements the full h.264 standard today, heck 16 reference frames of 1080p is using up 64Mb of vram in YV12 format already so not all cards can !). - then add support for an API that actually exposes that new functionality. VDPAU is probably our best candidate (short of creating our own API, which is a no-no for standardization reasons). Hi, What kind of GPU shading language are you using for mc and idct? Thanks Zou Nan hai Stephane --- --- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Google Summer of Code
Hi! I'm a GSoC student interested in the Gallium subjects which are about the implementation of VDPAU and OpenGL 3.0. I would like to start learning Gallium3D, so my question is: Do you have any useful learning resources to recommend as a starting point? Also I'm thinking about hacking on Gallium, something not too difficult, in order to get started. I'm already familiar with C, Xorg, git, compiling/installing, but still have a lot to learn about OpenGL. Denis -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
