Announcement

Collapse
No announcement yet.

Gallium3D Pipe-Video To Be Merged To Mesa Master

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

  • #11
    Originally posted by grigi View Post
    yeah, xrandr IS real dual screen.
    Can't get any better than that...

    I think the OP just confused xinerama and xrandr?

    Well, I have a E350 machine that would welcome this!
    So, waiting to test it soon!
    Well everybody makes mistakes... take you for example... you just confused dfx with michael (phoronix).. the latter of whom is the OP.

    Comment


    • #12
      Conceded, I did mean dfx.

      Anyways the point was, don't take things too literally where humans are involved :P

      Comment


      • #13
        Originally posted by grigi View Post
        yeah, xrandr IS real dual screen.
        Can't get any better than that...

        I think the OP just confused xinerama and xrandr?

        Well, I have a E350 machine that would welcome this!
        So, waiting to test it soon!
        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 ?

        Comment


        • #14
          Originally posted by DanL View Post
          This is dependent on your distro. Ubuntu has the xorg-edgers ppa and I'm sure other distros have already packaged mesa/3D stuff available. I use Debian and pull directly from git, so let me know if you want help with that.
          Thx for edgers. But I was thinking about pulling gits repos. But do not know what are dependencies, nor repos in question. (I have AMD 5730HD Mobile, OS is Ubuntu 11.04)

          So if you can give me detiled guide (ok I'm programist my self and know how to use git, but I would rather not found the hard way that I missed that one little lib-dev package I should installed beforehand )

          Thx for help!

          (Ps if you would be kind to inform me if there are any separete branches for power managment development, for r600g... that's main game stopper for me (and OGL4.1 or lack of it))

          Comment


          • #15
            Originally posted by przemoli View Post
            Thx for edgers. But I was thinking about pulling gits repos. But do not know what are dependencies, nor repos in question. (I have AMD 5730HD Mobile, OS is Ubuntu 11.04)

            So if you can give me detiled guide (ok I'm programist my self and know how to use git, but I would rather not found the hard way that I missed that one little lib-dev package I should installed beforehand )
            There's no magic involved.
            Today I used that PKGBUILD for archlinux.
            Code:
            pkgname=mesa-full-r600g
            pkgver=20110712
            _realver=7.12
            pkgrel=1
            pkgdesc="Full Mesa 3D graphics library with all its components, built from the git master branch (mesa 7.12). Compiles mesa for r600g (gallium)."
            arch=(i686 x86_64)
            url="http://mesa3d.org/"
            license=('LGPL')
            depends=('libdrm-git' 'dri2proto>=2.1' 'glproto>=1.4.10' 'libxxf86vm' 'libxdamage' 'expat>=2.0.1' 'libxmu' 'talloc' 'llvm')
            makedepends=('pkgconfig' 'imake' 'xorg-server-devel')
            optdepends=('llvm: "configure" tests for its presence and compiles with some additional "-D" macros if found')
            provides=("libgl=${_realver}" "mesa=${_realver}" "freeglut=${_realver}" "glut=${_realver}" "ati-dri=${_realver}")
            replaces=('libgl' 'mesa' 'freeglut' 'glut' 'ati-dri')
            conflicts=('libgl' 'mesa' 'freeglut' 'glut' 'ati-dri' 'mesa-full')
            
            _gitroot="git://anongit.freedesktop.org/git/mesa/mesa"
            _gitname="mesa"
            
            build() {
               msg "Connecting to git.freedesktop.org GIT server...."
            
               if [ -d $startdir/src/$_gitname ] ; then
                  cd $_gitname && git pull origin
                  msg "The local files are updated."
               else
                  git clone $_gitroot
               fi
            
               msg "GIT checkout done or server timeout"
               msg "Starting make..."
            
               rm -rf $startdir/src/$_gitname-build
               cp -rH $startdir/src/$_gitname $startdir/src/$_gitname-build
               cd ${srcdir}/${_gitname}-build
            
               cd "${startdir}/src/mesa-build"
               ./autogen.sh --prefix=/usr \
               --with-dri-drivers=r600 \
               --with-gallium-drivers=r600 \
               --with-dri-driverdir=/usr/lib/xorg/modules/dri \
               --enable-glx-tls \
               --enable-xcb \
               --enable-egl \
               --enable-gallium-egl \
               --enable-gallium-llvm \
               --enable-glu \
               --enable-gles1 \
               --enable-gles2 \
               --enable-glut \
               --enable-glw \
               --enable-openvg \
               --enable-xa \
               --enable-xorg \
               --enable-osmesa \
               --enable-texture-float \
               --enable-shared-glapi \
               --enable-shared-dricore \
               --enable-shared-driglx-direct \
               --enable-gbm \
               --enable-gallium-gbm || return 1
            
               make || return 1
               make DESTDIR="${pkgdir}" install || return 1
            
               install -m755 -d "${pkgdir}/usr/lib/xorg/modules/extensions"
               ln -sf libglx.xorg ${pkgdir}/usr/lib/xorg/modules/extensions/libglx.so || return 1
            }
            Should be easy to translate into a generic build.
            But it doesn't have the pipe video yet I think.

            Originally posted by przemoli View Post
            (Ps if you would be kind to inform me if there are any separete branches for power managment development, for r600g... that's main game stopper for me (and OGL4.1 or lack of it))
            I think mesa is the wrong place to look for in power management. That's probably mostly in the kernel. Maybe xf86-video-ati does play a role, don't know.

            Comment


            • #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

                      Working...
                      X