Announcement

Collapse
No announcement yet.

Mesa problem

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

  • #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; 30 August 2009, 01:29 PM.
    Test signature

    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.
                    Test signature

                    Comment

                    Working...
                    X