Announcement

Collapse
No announcement yet.

Gallium3D Pipe-Video To Be Merged To Mesa Master

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

  • #16
    Dynpm

    Originally posted by ChrisXY View Post
    I think mesa is the wrong place to look for in power management. That's probably mostly in the kernel.
    That's correct. It's in the kernel.

    Btw. I have almost fixed dynpm on my evergreen box. At least it's now usable!

    Some facts about dynpm and flickering on my system:

    1. There is simply not enough time during VBLANK to do everything the kernel code tries to do during reclocking. Even if the code is fixed to synchronize perfectly the time runs out in the middle and visible flickering occurs.

    2. The engine clock and voltage can be changed freely without syncing to vblank and so it should work fine with multiple monitors too. (This is very cool.) There is no flickering provided CRTCs are kept ON while doing the reclocking. (But there is probably some good reason why the code turns them OFF by default.)

    3. The memory reclocking is much harder to do without flickering. Even if synced perfectly to vblank the time runs out in the end and visible display corruption occurs. The solution is to start the reclocking just few lines BEFORE vblank. This way if there is any flickering it's limited to the last few lines only.

    4. When idle and working properly dynpm doesn't use any more power than the "low" profile, but it still responds immediately to any gpu load.

    I'm currently testing if these hacks are stable. I had some crashes when writing them, but I think the problems should be fixed now...

    Comment


    • #17
      Originally posted by ahlaht View Post
      That's correct. It's in the kernel.

      Btw. I have almost fixed dynpm on my evergreen box. At least it's now usable!

      Some facts about dynpm and flickering on my system:

      1. There is simply not enough time during VBLANK to do everything the kernel code tries to do during reclocking. Even if the code is fixed to synchronize perfectly the time runs out in the middle and visible flickering occurs.

      2. The engine clock and voltage can be changed freely without syncing to vblank and so it should work fine with multiple monitors too. (This is very cool.) There is no flickering provided CRTCs are kept ON while doing the reclocking. (But there is probably some good reason why the code turns them OFF by default.)

      3. The memory reclocking is much harder to do without flickering. Even if synced perfectly to vblank the time runs out in the end and visible display corruption occurs. The solution is to start the reclocking just few lines BEFORE vblank. This way if there is any flickering it's limited to the last few lines only.

      4. When idle and working properly dynpm doesn't use any more power than the "low" profile, but it still responds immediately to any gpu load.

      I'm currently testing if these hacks are stable. I had some crashes when writing them, but I think the problems should be fixed now...
      This is great news!
      Will this work with the hd4xxx series too?

      Comment


      • #18
        Originally posted by tball View Post
        This is great news! Will this work with the hd4xxx series too?
        They are fixes to the generic power management code so yes.

        That said I have not tested any other systems except mine. It's fairly easy to fix individual systems, but generally the kernel code needs to work on ALL systems from r1xx to NI. The current power management code in the kernel has been basically hacked to death because of this.

        My first "fix" was to remove the hack that disables clock speeds higher than the boot defaults. This hack is currently in the kernel because there is no code to automatically lower the clocks if the system seriously overheats. Temperature management needs to be added to properly fix this, but it should be be fairly easy. Someone just needs to write the code.

        My second "fix" was to remove the hack that disables the lowest clock modes because some systems do nyt work properly if they are used. Some other systems currently overheat because this hack exists in the kernel.

        My third (currently unimplemented) idea was to add some custom clock modes. While it can fix some systems, this is mostly for those who want to underclock or overclock their GPU.

        This fourth fix I just wrote about tries to prevent flickering while using dynpm at all cost. This is absolutely necessary because even the smallest desktop operations (properly) upclock the gpu if the lowest clock modes are in use. I really have no idea what this fix does on other systems. It may or may not work.

        Comment


        • #19
          Originally posted by dfx. View Post
          it does. it's when you have two completely separate screens (like :0.0 and :0.1) and not one stupid wide screen spanning across several outputs. so no window suddenly appear on wrong output or worse, half on one and half on another, unless they were explicitly originated there (like by running `DISPLAY=:0.1 mplayer -f <some file>`). but mouse still can travel across outputs.

          know how to do so with xrandr ?
          Why would merged view be a problem as long as we are talking about a single gpu and assuming both monitors are synced (both with vblank and each other)?

          Comment


          • #20
            Originally posted by liam View Post
            Why would merged view be a problem as long as we are talking about a single gpu and assuming both monitors are synced (both with vblank and each other)?
            "a problem" ? i never said anything about "a problem". i said what real _dual_ screen is, which is not _one_ wide screen but, you know, a duo.
            and i really would like to get an explanation myself about how to set this up with xrandr if it's really "can't get any better than that".

            heh, so much ugliness with this can't-get-any-better-than-that wide screen setup that you have to battle: not only everything stretched, popping up in random places but also you just have to synchronize both outputs to each other (have no idea about status of that). and for me, completely not worth the efforts since i hate so so much these wide-with-multiple-outputs screens.

            Comment


            • #21
              Wahey!

              Here's the commit: http://cgit.freedesktop.org/mesa/mes...184f31c845ccae

              Bostin!

              Comment


              • #22
                Mplayer2 status

                Great news! But unfortunately, Mplayer2 project leader decided to drop support for XvMC.

                Comment


                • #23
                  Originally posted by tom.higgy View Post
                  Yeah, I've done this just a couple of seconds ago, but what you are doing all day long? Hitting the refresh button?

                  But anyway my last commit to pipe-video didn't made it into the merge (I don't know why, git doesn't seems to like me), so please wait a few minutes until this get commited also.

                  Comment


                  • #24
                    Originally posted by pejakm View Post
                    Great news! But unfortunately, Mplayer2 project leader decided to drop support for XvMC.
                    There is still VDPAU to use. But any way it's ready for testing now.

                    Have fun, waiting for the bug reports to roll in.

                    Comment


                    • #25
                      Originally posted by Deathsimple View Post
                      There is still VDPAU to use. But any way it's ready for testing now.

                      Have fun, waiting for the bug reports to roll in.
                      Fantastic! I wasn't aware that VDPAU is working!

                      Comment


                      • #26
                        @Deathsimple:
                        Will you continue implementing support for other codecs?

                        Thanks a lot for your hard work so far!

                        Comment


                        • #27
                          Originally posted by Deathsimple View Post
                          Yeah, I've done this just a couple of seconds ago, but what you are doing all day long? Hitting the refresh button?
                          Nah, my RSS feed reader happened to pick it up about 20 minutes after the commit.

                          Thanks for all the effort you're putting into this.

                          Comment


                          • #28
                            I am building this now. This are my flags, I hope I didn't forget any.
                            Code:
                                autoreconf -vfi
                                ./autogen.sh --prefix=/usr \
                                --with-dri-drivers=r600 \
                                --with-gallium-drivers=r600 \
                                --with-dri-driverdir=/usr/lib/xorg/modules/dri \
                                --enable-gallium-llvm \
                                --enable-gallium-egl \
                                --enable-glx-tls \
                                --with-driver=dri \
                                --with-state-trackers=dri,glx,egl \
                                --enable-xcb \
                                --disable-glut \
                                --enable-gles1 \
                                --enable-gles2 \
                                --enable-egl \
                                --with-egl-platforms=x11,wayland,drm \
                                --enable-texture-float \
                                --enable-shared-glapi \
                                --enable-shared-dricore \
                                --enable-shared-driglx-direct \
                                --enable-gallium-svga \
                                --enable-patented \
                                --enable-vdpau \
                                --enable-xvmc \
                                --enable-va --enable-gallium-g3dvl
                              make

                            Comment


                            • #29
                              I am building tihs now and see if it works. I hope I did not forget any important flag.

                              Code:
                                 autoreconf -vfi
                                  ./autogen.sh --prefix=/usr \
                                  --with-dri-drivers=r600 \
                                  --with-gallium-drivers=r600 \
                                  --with-dri-driverdir=/usr/lib/xorg/modules/dri \
                                  --enable-gallium-llvm \
                                  --enable-gallium-egl \
                                  --enable-glx-tls \
                                  --with-driver=dri \
                                  --with-state-trackers=dri,glx,egl \
                                  --enable-xcb \
                                  --disable-glut \
                                  --enable-gles1 \
                                  --enable-gles2 \
                                  --enable-egl \
                                  --with-egl-platforms=x11,wayland,drm \
                                  --enable-texture-float \
                                  --enable-shared-glapi \
                                  --enable-shared-dricore \
                                  --enable-shared-driglx-direct \
                                  --enable-gallium-svga \
                                  --enable-patented \
                                  --enable-vdpau \
                                  --enable-xvmc \
                                  --enable-va --enable-gallium-g3dvl
                                make
                              Btw, you also have to install libvdpau.

                              Comment

                              Working...
                              X