Announcement

Collapse
No announcement yet.

PowerColor SCS3 Radeon HD 4650 512MB

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

  • PowerColor SCS3 Radeon HD 4650 512MB

    Phoronix: PowerColor SCS3 Radeon HD 4650 512MB

    Back in December we looked at the Sapphire Radeon HD 4650 512MB OC graphics card. This mid-range ATI graphics card had performed well under Linux and what separated it from the other Radeon HD 4650 graphics cards on the market was its factory overclock of 650/900MHz. While not factory overclocked beyond the RV730PRO specifications, PowerColor has the PowerColor SCS3 Radeon HD 4650 512MB, which instead offers passive cooling. Is this an ideal candidate for a Linux-based HTPC? In this article we are looking at the PowerColor SCS3 Radeon HD 4650 512MB.

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

  • #2
    The Catalyst driver does support XvMC
    It does? blabla ten character limit

    Comment


    • #3
      Originally posted by Zhick View Post
      It does? blabla ten character limit
      What the hell, 10 character limit?

      I would have thought all graphics cards be able to do hd (h264) playback acceleration by now. Even older cards like x1600 series..?

      Not sure I'm a fan of fanless GPU's either because usually they get very hot. So hot I could probably fry an egg on one.

      Comment


      • #4
        Just to be clear, the issue here is how *much* of the playback work is being accelerated, not whether there is acceleration at all.

        The open drivers currently accelerate scaling and colour space conversion, but not bitstream decode, IQ, IDCT or MC.
        Last edited by bridgman; 03-26-2009, 11:04 AM.

        Comment


        • #5
          Well, BitStream is one of most awaiting features for me ;-) On windows it works well, actually it's kinda funny to watch 1080p movie + 3 or 4 shaders combined with 0%CPU/0-2%GPU on HD4850, when CPU does the same with 30-40% of usage ;-)

          Comment


          • #6
            Bridgman, correct me if I'm wrong, but you get a better image quality using a GPU acceleration instead of a CPU acceleration. I have in mind that the more you use the GPU, the best picture you get (ride of artefact mpeg for example, better scaling, etc.)

            Because the GPU can achieve far more of this specific calculation than a CPU could ever do.

            Finally, the question is not so much acceleration (a quad core can do the job even for 1080i I guess) but rather for quality.
            Isn't it ?

            I'll also be very happy when it would be possible to encode videos using the GPU, as it's already possible to do with fglrx in Windows. I don't have windows, but even if my C2Q can handle my m2ts files conversions, I'll be more than happy to use my 4870 to convert my videos...

            Comment


            • #7
              Whats the point behind this card? Specs are a bit weird. Is it meant for only HTPC? GPU seems pretty powerful. But 128-bit is a little low perhaps? And DDR2?? Surely surely not for gaming .

              Comment


              • #8
                Originally posted by Fixxer_Linux View Post
                Bridgman, correct me if I'm wrong, but you get a better image quality using a GPU acceleration instead of a CPU acceleration. I have in mind that the more you use the GPU, the best picture you get (ride of artefact mpeg for example, better scaling, etc.)

                Because the GPU can achieve far more of this specific calculation than a CPU could ever do.
                Most of the opportunities to improve image quality (filtering, fancy di-interlacing, post-filtering etc..) are in the render part of the pipe, which is already accelerated.

                For the decode part of the pipe (the first part) you basically "follow the instructions" with very few opportunities to improve quality.

                Most of the image enhancement stuff is shader-based, working on the fully decoded image, so it pretty much has to be in the "render" part of the pipe. You can think of the Xv API as the dividing line between "decode" and "render".

                The order of the last few steps can change, and steps can be combined in a single shader :

                bitstream <<- VDPAU, VA-API, XvBA start here (or lower)
                IQ
                IDCT <<- XvMC starts here
                MC <<- or here
                deblock
                colour space conversion <<- Xv starts here
                post-filtering
                de-interlacing
                scaling

                ---------


                Originally posted by Fixxer_Linux View Post
                Finally, the question is not so much acceleration (a quad core can do the job even for 1080i I guess) but rather for quality. Isn't it ?
                Decode acceleration is mostly about reducing CPU utilization and power consumption. Render acceleration does as much or more to reduce CPU utilization, but there are also opportunities to improve image quality. Scaling and MC usually put the biggest load on the CPU.

                All of the steps from MC down are great candidates for processing with shaders. Most of the earlier steps (from IQ on down) can also be done on shaders but dainty, dedicated hardware can usually do the same work with less power consumption.
                Last edited by bridgman; 03-26-2009, 01:40 PM.

                Comment


                • #9
                  Originally posted by bridgman View Post
                  The order of the last few steps can change, and steps can be combined in a single shader :

                  bitstream <<- VDPAU, VA-API, XvBA start here (or lower)
                  IQ
                  IDCT <<- XvMC starts here
                  MC <<- or here
                  deblock
                  colour space conversion <<- Xv starts here
                  post-filtering
                  de-interlacing
                  scaling
                  So does that mean around 25% of that stack is currently being accelerated by the GPU?

                  Comment


                  • #10
                    In terms of steps, I guess it's 4 out of 9 or 44%. In terms of CPU it's probably about the same or maybe a bit lower -- MC and scaling are the biggest CPU hogs.

                    The relative CPU utilization in the different stages changes a fair amount depending on the encoder and the encoding parameters that were used.

                    Comment


                    • #11
                      Originally posted by bridgman View Post
                      In terms of steps, I guess it's 4 out of 9 or 44%. In terms of CPU it's probably about the same or maybe a bit lower -- MC and scaling are the biggest CPU hogs.

                      The relative CPU utilization in the different stages changes a fair amount depending on the encoder and the encoding parameters that were used.
                      let me guess:

                      bitstream (no accel)
                      IQ (no accel)
                      IDCT (no accel)
                      MC (no accel)
                      deblock (no accel)
                      colour space conversion (accel)
                      post-filtering (accel)
                      de-interlacing (accel)
                      scaling (accel)

                      I'm probably waaaay off. :P

                      Comment


                      • #12
                        Bingo. Sorry I didn't make that clear -- everything from the entry point down is accelerated.

                        You pretty much have to do it that way -- accelerating part of the stack, then doing some in CPU, then accelerating some more is usually slower than doing everything in CPU to a certain point then doing the rest on the GPU, since pulling partially processed frames back to system memory is slow and having the CPU work in video memory is slow too.

                        Comment


                        • #13
                          Originally posted by bridgman View Post
                          You pretty much have to do it that way -- accelerating part of the stack, then doing some in CPU, then accelerating some more is usually slower than doing everything in CPU to a certain point then doing the rest on the GPU, since pulling partially processed frames back to system memory is slow and having the CPU work in video memory is slow too.
                          Ah yep the limited bandwidth of the AGP / PCI-X bus. This pretty much reminds me of some optimizations that are required for games. Same sort of thing with triangles and textures.

                          Comment


                          • #14
                            Nice!

                            Hooray for fanless average performance video cards! I've got a 2600 XT fanless and it's great. I can play almost anything released before 2008 with max details, which is fine cause I can never keep up with the current-year game releases anyway.

                            I'd really like to see a comparison benchmark between this and the 2600 XT but I'll take what you have

                            Comment


                            • #15
                              Originally posted by bridgman View Post
                              In terms of steps, I guess it's 4 out of 9 or 44%. In terms of CPU it's probably about the same or maybe a bit lower -- MC and scaling are the biggest CPU hogs.

                              The relative CPU utilization in the different stages changes a fair amount depending on the encoder and the encoding parameters that were used.
                              Does this also means that this also work for MPEG4 videos and all newer HD formats, like blu-rays or AVCHD ?

                              Comment

                              Working...
                              X