Announcement

Collapse
No announcement yet.

Easiest way to switch between xorg-edgers and git?

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

  • Easiest way to switch between xorg-edgers and git?

    Short story: If I want to try installing mesa from git and later switch back to xorg-edgers, how would I do it? I'd rather not get stuck always pulling and building my own tree, only when I work on it which will be occasionally.

    Long story: After digging around a bit trying to figure out where some error messages were coming from I found they are from mesa (function EG_GetNumOperands(GLuint opcode, GLuint nIsOp3) in /src/mesa/drivers/dri/r600/r700_assembler.c).

    So far so good, and I understand that problem as it's an instruction not listed there I found in the shader docs and I think I have a working patch though I'm sure there's more to be done.

    I got all the prerequisites for building mesa finally and make runs without error. I just haven't dared run make install because I need a way to back it out...

  • #2
    Just copy r600_dri.so from your build tree or adjust the LIBGL_DRIVERS_PATH env var to point to the new r600_dri.so

    Comment


    • #3
      Originally posted by agd5f View Post
      Just copy r600_dri.so from your build tree or adjust the LIBGL_DRIVERS_PATH env var to point to the new r600_dri.so
      I run a 64 bit system and when I run locate r600_dri.so I get:
      /usr/lib/dri/r600_dri.so
      /usr/lib32/dri/r600_dri.so

      in addition to my own. I'm guessing the default build (I just ran make) makes 64 bit, but can I replace just one or do I need to compile a 32 bit version too? Also, why is my compiled version (18 MB) so much bigger than the installed versions (3-4 MB)? Is there some debug or static linking settings that are on by default? I just got it from git, ran autoconf then make...

      Comment


      • #4
        Your distro likely uses the dricore patch, it's not in the upstream mesa.

        Comment


        • #5
          Originally posted by Kjella View Post
          I run a 64 bit system and when I run locate r600_dri.so I get:
          /usr/lib/dri/r600_dri.so
          /usr/lib32/dri/r600_dri.so

          in addition to my own. I'm guessing the default build (I just ran make) makes 64 bit, but can I replace just one or do I need to compile a 32 bit version too? Also, why is my compiled version (18 MB) so much bigger than the installed versions (3-4 MB)? Is there some debug or static linking settings that are on by default? I just got it from git, ran autoconf then make...
          You need the 32 bit one for 32 apps. If you aren't testing any 32 bit apps, there is no need to build the 32 bit version. The default mesa build has debugging symbols included so that increases the size.

          Comment


          • #6
            Originally posted by agd5f View Post
            You need the 32 bit one for 32 apps. If you aren't testing any 32 bit apps, there is no need to build the 32 bit version. The default mesa build has debugging symbols included so that increases the size.
            Sigh, one step forward and two back. I'm trying to run a game from wine, and is using 32 bit (checked it with ldd too). I've managed to install the multilib packages needed to compile 32 bit under 64 bit (which was not an obvious process) but when I run "make linux-dri-x86" I get:

            -rwxr-xr-x 1 kjella kjella 14307822 2010-10-25 15:16 r128_dri.so
            -rwxr-xr-x 1 kjella kjella 15666867 2010-10-25 15:17 r200_dri.so
            -rwxr-xr-x 1 kjella kjella 15944867 2010-10-25 15:17 r300_dri.so
            -rwxr-xr-x 1 kjella kjella 15479030 2010-10-25 15:17 radeon_dri.so

            ...but no r600_dri.so. I can see from the gcc commands that -m32 is set, so at least 32 bit compiles work. But do I need some other target for make? For 64 bit, I just ran make - which the docs say should give me a list of possible build targets instead, but not on maverick at least.

            Comment


            • #7
              maybe try specifying the drivers you want to build when running autogen.sh:
              --with-dri-drivers=swrast,radeon,r200,r300,r600

              Comment


              • #8
                Originally posted by Kjella View Post
                I just haven't dared run make install because I need a way to back it out...
                If you create a new user and set some new environment variables using .bashrc or .bash_profile you can install to and run from any directory?in essence it would be like using two distrubutions on the same computer. I was thinking of posting a guide for such. So you could install things like gcc-git, xorg-git, kde4-svn without effecting the rest of your OS and access that system with a certain username login.

                Comment


                • #9
                  Originally posted by agd5f View Post
                  maybe try specifying the drivers you want to build when running autogen.sh:
                  --with-dri-drivers=swrast,radeon,r200,r300,r600
                  Got it to work finally, as you can either pick a make target or use autogen.sh I had to find the right autogen switch (--enable-32-bit) to force it into 32 bit on a 64 bit machine.

                  What's the proper place to submit patches? This oneliner cut my error output with 300kb, the instruction has two inputs instead of being unknown. I still got plenty other issues though, but I think I need blit support because it complains of being out of memory so I'm going to try installing a new daily kernel now that the 2.6.37 window is open:

                  Code:
                  diff --git a/src/mesa/drivers/dri/r600/r700_assembler.c b/src/mesa/drivers/dri/r
                  index 2bf2409..696322e 100644
                  --- a/src/mesa/drivers/dri/r600/r700_assembler.c
                  +++ b/src/mesa/drivers/dri/r600/r700_assembler.c
                  @@ -450,6 +450,7 @@ unsigned int EG_GetNumOperands(GLuint opcode, GLuint nIsOp3)
                       case EG_OP2_INST_KILLGT:
                       case EG_OP2_INST_KILLGE:
                       case EG_OP2_INST_KILLNE:
                  +    case EG_OP2_INST_LSHR_INT:
                       case EG_OP2_INST_MUL: 
                       case EG_OP2_INST_MAX:
                       case EG_OP2_INST_MIN:

                  Comment


                  • #10
                    Hmm nope, I installed the drm-next kernel from:

                    built the 26th. That should have access to the full memory right? Yet I get these:

                    err:d3d:resource_init Out of adapter memory
                    err:d3d9:device_parent_CreateSurface (0x14aa94) CreateSurface failed, returning 0x8876017c
                    fixme:d3d_texture:texture_init Failed to create surface 0x5fbbc4a8, hr 0x8876017c

                    It's creating lots of textures up until it hits that point, so it really looks like I've hit some memory limit. I read something earlier about it being limited to PCI aperture size and that a blit patch for 2.6.37 would fix it, but I have that one now right? This one:

                    Comment

                    Working...
                    X