Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: Gallium3D Pipe-Video To Be Merged To Mesa Master

  1. #11
    Join Date
    Oct 2009
    Posts
    2,064

    Default

    Quote 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.

  2. #12
    Join Date
    Jan 2008
    Location
    South Africa
    Posts
    228

    Default

    Conceded, I did mean dfx.

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

  3. #13
    Join Date
    Jan 2009
    Posts
    191

    Default

    Quote 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 ?

  4. #14
    Join Date
    Sep 2010
    Posts
    654

    Default

    Quote 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))

  5. #15
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,023

    Default

    Quote 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.

    Quote 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.

  6. #16
    Join Date
    May 2011
    Posts
    58

    Default Dynpm

    Quote 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...

  7. #17
    Join Date
    Jan 2009
    Posts
    515

    Default

    Quote 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?

  8. #18
    Join Date
    May 2011
    Posts
    58

    Thumbs up

    Quote 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.

  9. #19
    Join Date
    Jan 2009
    Posts
    1,308

    Default

    Quote 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)?

  10. #20
    Join Date
    Jan 2009
    Posts
    191

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •