Announcement

Collapse
No announcement yet.

ATI Radeon HD 4850 512MB

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

  • #46
    Originally posted by deanjo View Post
    The primary reason why people can detect flicker @ 60 Hz is because of the occasional synchronization of artificial light sources and the refresh rate of the monitor (in countries that have a 50 Hz powergrid this effect happens at that refresh rate). It is the same effect as to why when filming a crt screen with a camera you will see scan lines on the screen. This effect does not happen on LCD's as the pixel state (as you have mentioned) changes discreetly.
    I think we are both being a little bit liberal and coarse with our interpretation and description of phenomena and effects. But to continue the interesting discussion...

    The eye (and brain which is part of the picture) are analog, you may be able to perceive something you can't see under close examination. CRT flicker is more noticable in your peripheral vision and not your direct vision. Your eye does not "capture" at 25 Hz, it has a response time, some persistance in light detection, and the brain also applies it's own interpretation. You can detect a flash of 1/4000 of a second, but would not be able to see a light that is oscillating on and off at 1/60th of second.

    LED lights demonstrate this. You look at the light directly and it is 100% solid and unwavering, you scan your eyes to the left or right, and you will see a collection of discrete images of the lights as you "capture" the light in being on and off in different parts of your field of view.

    I agree that there may be *some* aliasing between the local power source (as applied to lighting) and CRTs, but almost all domestic lighting uses some method of persistance (either phosphorus in flourescent tubes and CFLs), or in the case of tungsten lighting, the filament doesn't cool down enough before it heats up for the next AC cycle.

    Also, bear in mind though that the VESA "flicker-free" standards applied just as correctly moving from 60 to 72 Hz in Australia as it did in North America.

    The aliasing you are talking about when filming is a related, but more or less discrete effect. The frames capture a finite amount of light, and the CRT monitors on the set will be emitting (or scanning out) a fixed number scanlines in that period. As a result the captured image will never be full frames, this coupled with phosphor decay will results in the historically familiar dark horizontal lines on TV and movies. With LCDs, this simplifies down to tearing on screens. Framelock and Genlock provide a solution to this, by ensuring that all displays on a set will be synchronized to a common clocking signal that is in sync with the camera.

    Regards,

    Matthew

    Comment


    • #47
      How to run fglrx on it ?

      The bottom line right now is there are a few troubles with the Catalyst 8.6 for Linux and the Radeon HD 4850.
      So it seems that you have manged to run it. How did you do that ? I'm stuck on SIGSEGV somewhere in userland part of fglrx while trying to start X.

      Regards,
      rle

      Comment


      • #48
        Originally posted by rlewczuk View Post
        So it seems that you have manged to run it. How did you do that ? I'm stuck on SIGSEGV somewhere in userland part of fglrx while trying to start X.

        Regards,
        rle
        What motherboard/chipset are you using? You may need to update your BIOS to circumvent a bug with the driver.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #49
          Originally posted by Michael View Post
          What motherboard/chipset are you using? You may need to update your BIOS to circumvent a bug with the driver.
          Whoops, wrong driver version (I've downloaded 8.501 BUT then installed 8.49.4), sorry for this redundant rambling :-). Now everything seems to be working fine.

          The good news is that AMD Stream SDK is also working (I've bought this card just for it). I've compiled and run all CAL and Brook+ examples from SDK. Except for some assertion messages (this is a known CAL/Ubuntu problem) all are working good.

          My system was Asus P5B + E6300 + 2GB RAM (reduced from 4GB to get the card running first and solve MTRR problems later).

          I still didn't benchmark CAL/Brook+ as I'm a newbie in this topic (and need to move the card to a more decent machine first).

          Regards,
          rle

          Comment


          • #50
            Michael, since you've got both HD4850 and HD4870, could you also mention in the tests if the cards suspend/hibernate/resume nicely, using the proprietary drivers and the open source ones?

            Since all the cards released at the moment are the same (only the branding differs), that information would prove really useful!

            Thanks a lot.

            Comment


            • #51
              Originally posted by miles View Post
              Michael, since you've got both HD4850 and HD4870, could you also mention in the tests if the cards suspend/hibernate/resume nicely, using the proprietary drivers and the open source ones?

              Since all the cards released at the moment are the same (only the branding differs), that information would prove really useful!

              Thanks a lot.
              Hi,

              Suspend/Resume is dependent on a lot of different factors, only a few of them are related to the graphics driver. Different kernel versions, different patch-sets, different suspend scripts all make it nearly impossible to say that suspend/resume works in all cases.

              That said, our standard testing (which occurs on RHEL and SuSE), does test S3 and S4 on most hardware.

              Regards,

              Matthew

              Comment


              • #52
                Originally posted by mtippett View Post
                Hi,

                Suspend/Resume is dependent on a lot of different factors, only a few of them are related to the graphics driver. Different kernel versions, different patch-sets, different suspend scripts all make it nearly impossible to say that suspend/resume works in all cases.

                That said, our standard testing (which occurs on RHEL and SuSE), does test S3 and S4 on most hardware.

                Regards,

                Matthew
                True, but if the machine he's using suspends and resumes nicely already, changing the graphic card with the model he wants to test (an HD4850 or 4870 here) wouldn't it give a fair indication about the card itself?

                Comment


                • #53
                  Originally posted by miles View Post
                  True, but if the machine he's using suspends and resumes nicely already, changing the graphic card with the model he wants to test (an HD4850 or 4870 here) wouldn't it give a fair indication about the card itself?
                  Yes, that is true, but in general, the suspend/resume issues are triggered not by the Hardware, but by the SW ecosystem described above.

                  Also note that some of the suspend hacks (like reposting cards, etc) will may work on some cards and not. But as I mentioned before, they are mainly hacks that should generally be avoided.

                  Regards,

                  Matthew

                  Comment


                  • #54
                    Feature parity?

                    Feature parity? Does that mean that fglrx finally supports screen rotation?

                    Comment


                    • #55
                      Hi
                      I am trying to patch and build the Open source ATI driver for my new 4850 card, as per Michael's instructions. When run the command

                      patch -p0 < ~/rv770-id.patch

                      this is the output
                      can't find file to patch at input line 4
                      Perhaps you used the wrong -p or --strip option?
                      The text leading up to this was:
                      --------------------------
                      |diff -Naur xf86-video-ati.orig/src/ati_pciids_gen.h xf86-video-ati/src/ati_pciids_gen.h
                      |--- xf86-video-ati.orig/src/ati_pciids_gen.h 2008-06-19 14:36:59.000000000 -0400
                      |+++ xf86-video-ati/src/ati_pciids_gen.h 2008-06-19 14:38:40.000000000 -0400
                      --------------------------
                      File to patch:


                      I got the git code from

                      git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati


                      The patch file is on my home dir, the code is also at the same level (in the xf86-video-ati folder)

                      Any help would be highly appreciated.

                      Thanks
                      Leo.

                      Comment


                      • #56
                        Leo:

                        What's your current directory when running the command? It should be one directory lower than xf86-video-ati. Otherwise just type the relative path to those files.
                        Michael Larabel
                        http://www.michaellarabel.com/

                        Comment


                        • #57
                          Usually you use -p1.

                          Comment


                          • #58
                            Originally posted by Kano View Post
                            Usually you use -p1.
                            I think that worked. Here are the steps that I followed

                            sudo apt-get install build-essential git-core configure-debian automake autoconf xorg-dev libtool

                            git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati

                            cd xf86-video ati
                            patch -p1 < ~/rv770-id.patch
                            ./autogen.sh --prefix=/usr/
                            make
                            sudo make install
                            make clean

                            sudo nano /etc/X11/xorg.conf

                            find the device section. In the line "Driver" substitute "ati" for whatever is there now....i.e., vesa or fglrx

                            However, when I made changes to XORG file and rebooted, the screen turned white and I had to reboot and come into Recovery mode to reset the xorg.conf file.
                            One thing I noticed is that after I reset the file, I can now use full 1280 X 1024 resolution. However, ATI catalyst control center still doesnt recognize the card or start. Can someone share how to find if the patch worked? and also send the Xorg.conf file contents?

                            Thanks
                            Leo

                            Comment


                            • #59
                              Try removing the file or using

                              dpkg-reconfigure xserver-xorg

                              for some language selections. For standard xservers you don't need much in there.

                              Comment


                              • #60
                                Originally posted by mtippett View Post
                                Yes, that is true, but in general, the suspend/resume issues are triggered not by the Hardware, but by the SW ecosystem described above.

                                Also note that some of the suspend hacks (like reposting cards, etc) will may work on some cards and not. But as I mentioned before, they are mainly hacks that should generally be avoided.
                                One reason people using Linux tend to prefer Intel's IGP is because the suspend/resume works in most (all?) distributions without having to hack it in yourself. Oter IGP and dedicated hw can often resume, but to a blank screen or a messed up one. Having similar success as Intel's IGP would be an important feature to know before purchasing the hardware

                                Edit: and I know I'm comparing apples to oranges, since Intel's IGP will never do more than 2D in Linux, while ATI's open source drivers should offer 2D, 3D, possibly hw video decode and a perfect suspend/hibernate experience in the future. It's just that getting updated about suspend/resume advances can be as important as updates on 3D or hw video decode.
                                Last edited by miles; 07-01-2008, 06:51 AM.

                                Comment

                                Working...
                                X