Announcement

Collapse
No announcement yet.

Mesa 9.0 Officially Released, Supports OpenGL 3.1

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by ssam View Post
    so what would i need to start playing with openCL and clover? I guess i'd need a newer card than a HD3650. is clover complete enough to compile GEGL and have an openCL enabled GIMP?
    Not sure how complete it is, but you'll need a Radeon HD 5000 class or higher.

    Comment


    • #17
      Originally posted by ryszardzonk View Post
      I do think that Xvid or x264 efforts are patented. Besides I would rather disagree there is not much to gain with hardware decoding. There is pleanty of devices which cope with decoding of Full HD material only if done by the graphics driver example of which would be many low powered devices including AMD E-350 which I am happy owner of.

      IMHO it would be great gain for Linux in general if one could use device like that to it full extend therefore I believe that mesa should extend its vdpau implementation or add a way to use external vaapi that is done so great by Intel guys
      I think (please someone correct me if im wrong :P) but what is being talked about here is shader based acceleration?? Not via the video decoding unit in amd/nVidia gpu's (for OSS drivers). So an E350 would have a lot harder time decoding than a desktop grade GPU with more shaders.

      Comment


      • #18
        Originally posted by zeealpal View Post
        I think (please someone correct me if im wrong :P) but what is being talked about here is shader based acceleration?? Not via the video decoding unit in amd/nVidia gpu's (for OSS drivers). So an E350 would have a lot harder time decoding than a desktop grade GPU with more shaders.
        yes you are right. I tend to confuse those too as I am looking at things more from the user perspective who occasionaly does some bug reports and traslation stuff not the developer. Programing seems to technical for me, but what I am getting at is that one way or another users in general would welcome hardware / gpu decoding in the opensource drivers to the extend it is being done in closed source counter-parts and if am not mistaken there is no shader or any other acceleration for r600 driver that would let decode 1080p sources using that driver

        Comment


        • #19
          Originally posted by ryszardzonk View Post
          I do think that Xvid or x264 efforts are patented.
          Yeah, they're patented. But that's irrelevant, mpeg2 is patented too and yet Gallium has a decoder for it.

          Originally posted by ryszardzonk View Post
          Besides I would rather disagree there is not much to gain with hardware decoding. There is pleanty of devices which cope with decoding of Full HD material only if done by the graphics driver example of which would be many low powered devices including AMD E-350 which I am happy owner of.
          Your E-350 decodes Full HD using a dedicated hardware decoder (UVD) that the fglrx driver has access to. But I wasn't talking about a dedicated decoder, I was talking about the GPU. The GPU is bad at decoding.

          Originally posted by ryszardzonk View Post
          IMHO it would be great gain for Linux in general if one could use device like that to it full extend therefore I believe that mesa should extend its vdpau implementation or add a way to use external vaapi that is done so great by Intel guys
          Adding vaapi to Gallium wouldn't change anything when it comes to AMD. It's not about the API, it's getting access to UVD. We don't have documentation to do that, so Gallium can only use the GPU (shaders) for decoding. And writing a shader-based h264 decoder would be a lot of effort for little gain, it's not worth it.
          Last edited by Gusar; 10-09-2012, 11:08 AM.

          Comment


          • #20
            Originally posted by dogsleg View Post
            What is the state of radeonsi? When it is planned to be ready?
            It currently runs lots of 3D demos and basic games, including piglit. I think the biggest thing left is shaking out the remaining bugs in the flow control code in the shader compiler. Once that's working properly we can enable more glamor features and more advanced games should start working.

            For the current todo list see:
            http://dri.freedesktop.org/wiki/RadeonsiToDo

            Comment


            • #21
              Originally posted by Gusar View Post
              This isn't about patents, it's about one simple thing: GPUs aren't actually suitable for video decoding. A lot of effort required for not much gain.
              Yeah, I've been preaching this for YEARS, but most people apparently still like to believe in fairies. Shader-based video decoding is simply useless for the vast majority of configurations. You can't offload some of the most demanding parts of the pipeline, it's WAY more power-guzzling than CPU decoding, and you need a somewhat beefy GPU to start with.

              But it's still good to have VDPAU, as it provides a very capable presentation layer, much better than the old Xvideo.

              Comment


              • #22
                Originally posted by brent View Post
                But it's still good to have VDPAU, as it provides a very capable presentation layer, much better than the old Xvideo.
                Can you expand on that - what am I missing by still using XV?

                Comment


                • #23
                  Originally posted by curaga View Post
                  Can you expand on that - what am I missing by still using XV?
                  Well, here's a quick list. Xv doesn't provide

                  - frame queueing and accurate display timing. This is especially problematic if video FPS are higher or equal to the display refresh rate
                  - any notable control over colorspace conversion and only limited control over image color settings
                  - any notable control over scaling quality
                  - subpicture composition for OSD/subtitles
                  - deinterlacing
                  - RGB formats (only few implementations of Xv can do that)
                  - 10bpp formats
                  - interoperability with OpenGL

                  and these are, IMHO, very important features. Xvideo is still common because it is usually the least common denominator, but this is really holding Linux back with respect to video output quality and capability, compared to OS X or Windows.

                  Comment


                  • #24
                    Thanks.

                    Doesn't seem I'm missing much then, not being that big a movie-phile. My XV output does vsync, offers either bilinear or bicubic scaling, and mplayer seems to manage to show subtitles

                    Comment


                    • #25
                      Originally posted by curaga View Post
                      and mplayer seems to manage to show subtitles
                      Take SD video with subtitles, playback it to FullHD display and compare quality of subtitle rendering between xv and OpenGL output.

                      Comment


                      • #26
                        Originally posted by Gusar View Post
                        Your E-350 decodes Full HD using a dedicated hardware decoder (UVD) that the fglrx driver has access to. But I wasn't talking about a dedicated decoder, I was talking about the GPU. The GPU is bad at decoding.
                        I know one can use fglrx but ufortunetly it is not without issues either which quick search shows. Therefore I much rather follow development of the open source driver version - r600 in my case.

                        Originally posted by Gusar View Post
                        Adding vaapi to Gallium wouldn't change anything when it comes to AMD. It's not about the API, it's getting access to UVD. We don't have documentation to do that, so Gallium can only use the GPU (shaders) for decoding. And writing a shader-based h264 decoder would be a lot of effort for little gain, it's not worth it.
                        Well for me regular John Doe shaders or not I would love to see improvements in video decoding department for AMD chips so I would not have think twice before purchasing their hardware in the future, but I do admit it went long way already for both fglrx and r600 with the resources comitted to the development


                        EDIT: More bugs out of fglrx here, but seems there is progres on that part which I was not aware of. Anyone can confirm this trick works which I found on the very end of this thread?

                        amdconfig --set-pcs-u32=MCIL,HWUVD_H264Level51Support,1

                        EDIT2: I hope I did not piss anyone off as this happened right after my post

                        http://cgit.freedesktop.org/mesa/mes...61cf0955c33072
                        Last edited by ryszardzonk; 10-09-2012, 05:22 PM.

                        Comment


                        • #27
                          Maybe as 3rd party library? But not in mainland mesa.

                          Comment


                          • #28
                            Originally posted by RussianNeuroMancer View Post
                            Take SD video with subtitles, playback it to FullHD display and compare quality of subtitle rendering between xv and OpenGL output.
                            Yep, I do see the difference there. So XV subtitles are done at the video resolution then?

                            Though, GL output is no solution when it takes multiple times the cpu of XV. Can anyone compare the cpu overhead of vdpau (presentation only) to xv?

                            Comment


                            • #29
                              Yes, with Xvideo subtitles and OSD have to be rendered into the video, with all associated problems. I.e. blurry text with low-res video, video aspect ratio affects subtitle/OSD rendering, and subtitle/OSD rendering is restricted to the same colorspace and video mixer settings as the video.

                              If you have a capable driver, MPlayer's OpenGL output is similarly efficient as Xv or VDPAU. That is, the overhead is negligible.
                              Last edited by brent; 10-10-2012, 05:50 AM.

                              Comment


                              • #30
                                Originally posted by ryszardzonk View Post
                                Anyone can confirm this trick works which I found on the very end of this thread?
                                It works with XBMC-XvBA and patched xvba-va-driver.

                                Comment

                                Working...
                                X