Announcement

Collapse
No announcement yet.

Mesa problem

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

  • #16
    Did you do a "make" and "sudo make install" from the drm folder to build and install libdrm before going down to linux-core to build and copy the kernel modules ? Wondering if this is a mismatch between drm and libdrm versions.

    Comment


    • #17
      i didnt at the beggining but i did it later and install all again including make - make install with prefix=/usr ofc in the drm folder and re copied later the drm.ko / radeon.ko from linux-core. but ill try a make clean do it from start again tomorrow to be sure. ihad this problem the first but using a staging kernel got fixed, but this time i dont know where find a newest kernel than 2.6.31 rc8. mmm thinking about it maybe the rc8 is too new for latest drm git? just a thougth
      Last edited by jrch2k8; 08-30-2009, 01:23 AM.

      Comment


      • #18
        Originally posted by jrch2k8 View Post
        i did that already but radeon.ko try to load ttm.ko, im sure radeon.ko and drm.ko are the rigth ones cuz i delete all except tmm from drm folder and cp those modules only
        As said, if it's loaded in initrd, it doesn't make any different which files you replace before you create a new initrd. The modules are actually inside the initrd.

        Comment


        • #19
          I would think no one should put video drivers or other similar modules in the initrd as their not required for booting. The video, sound, tv-capture, and in most cases network modules can be loaded as modules after booting into the kernel.

          In the odd event I use my initrd, all I ever have in it is the ide/sata and filesystem (ext2, ext3, jfs, xfs, and maybe vfat/ntfs). That's the minimum I need to boot.

          What is rationale for why karmac has drm in initrd?

          Edit: if this is case, make a new initrd in your /boot folder:
          Something like:
          mkinitrd -c -k <your kernel, the number needs to be in /lib/modules/> -m ext2:ext3:xfs

          There are other options but this works for me.
          Last edited by forum1793; 08-30-2009, 10:55 AM.

          Comment


          • #20
            Actually with KMS you probably want to put them either in initrd or have them inbuilt if you want them loaded in early boot. (ttm hints to them shipping KMS for earlier chips)

            Comment


            • #21
              Originally posted by forum1793 View Post
              I would think no one should put video drivers or other similar modules in the initrd as their not required for booting. The video, sound, tv-capture, and in most cases network modules can be loaded as modules after booting into the kernel.
              KMS is all about moving display driver code into the kernel, specifically the drm driver, so that the same display driver can be used for booting, consoles, and X. This pretty much requires that drm be in the initrd so that the display can be initialized early in the boot process. Prior to KMS, the boot sequence used one driver, X used another, and consoles used a third, all taking turns controlling the hardware without any knowledge of how the other drivers programmed it.
              Last edited by bridgman; 08-30-2009, 01:29 PM.

              Comment


              • #22
                Originally posted by forum1793 View Post
                I would think no one should put video drivers or other similar modules in the initrd as their not required for booting. The video, sound, tv-capture, and in most cases network modules can be loaded as modules after booting into the kernel.

                In the odd event I use my initrd, all I ever have in it is the ide/sata and filesystem (ext2, ext3, jfs, xfs, and maybe vfat/ntfs). That's the minimum I need to boot.

                What is rationale for why karmac has drm in initrd?

                Edit: if this is case, make a new initrd in your /boot folder:
                Something like:
                mkinitrd -c -k <your kernel, the number needs to be in /lib/modules/> -m ext2:ext3:xfs

                There are other options but this works for me.
                I don't even have an initrd.
                I either compile everything I need into my kernel, or just load up modules.

                Comment


                • #23
                  is working now, i just removed ttm.ko from kernel XD it gives a warning but it works. but the actual render 1600 in glxgears and opengl 1.4 but wine almost work in 3d mode. nice progress XD

                  Comment


                  • #24
                    Originally posted by bridgman View Post
                    KMS is all about moving display driver code into the kernel, specifically the drm driver, so that the same display driver can be used for booting, consoles, and X. This pretty much requires that drm be in the initrd so that the display can be initialized early in the boot process. Prior to KMS, the boot sequence used one driver, X used another, and consoles used a third, all taking turns controlling the hardware without any knowledge of how the other drivers programmed it.
                    But when you load a module into the kernel, doesn't it essentially become part of the kernel. Modules allow the kernel to be much smaller. Why can't the kernel boot with a simple vga module which is then unloaded and the kms-drm (whatever) modules are loaded during boot?

                    Comment


                    • #25
                      Originally posted by pvtcupcakes View Post
                      I don't even have an initrd.
                      I either compile everything I need into my kernel, or just load up modules.
                      I'm usually the same but the slackware distros come with a generic kernel which then requires the initrd to work. Their generic kernel doesn't even have ext2 built in.

                      Every now and then it's useful to boot up a generic with all the modules just to see which ones your hardware grabs. It gives you an idea about what to enable as modules when you build a custom kernel. Takes some guess-work out

                      Comment


                      • #26
                        Originally posted by forum1793 View Post
                        But when you load a module into the kernel, doesn't it essentially become part of the kernel. Modules allow the kernel to be much smaller. Why can't the kernel boot with a simple vga module which is then unloaded and the kms-drm (whatever) modules are loaded during boot?
                        This would introduce a latency before you get your framebuffer console. In some hardware environments this would be bad.

                        Comment


                        • #27
                          well this is bad only cuz amd drm code is not completly in the kernel yet, so prolly for 2.6.32 these wont be an issues unless you wanna try bleeding edge code

                          Comment


                          • #28
                            Originally posted by bridgman View Post
                            Why are you saying drm works just fine ? I don't thing glxinfo uses drm; it just requires that the GL driver can load and initialize drm, not that the actual command submission functions are there.
                            Just a little nitpick:

                            glxinfo does create a GL context (it has to query the extension list, after all), and thus the driver will do the whole DRI (or DRI2) initialization dance, including opening a DRM fd (one reason why this is necessary anyway is that we need to check the DRM version to determine which extensions are supported by the DRM - the DRM doesn't know about 3D, but it *does* know about register validity, so if some register has only been added in a later version of the DRM, we need to check that).

                            Of course, glxinfo shouldn't submit any command streams, that would be just wrong.

                            Comment


                            • #29
                              Agreed. My reading of the situation was that drm included X server support and was being initialized properly (allowing glxinfo to work) but since the 3D support wasn't there the drm blew chunks on the first command submission.

                              Comment

                              Working...
                              X