Announcement

Collapse
No announcement yet.

Mesa problem

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

  • jrch2k8
    started a topic Mesa problem

    Mesa problem

    hi, im back testing my 4850x2 card in OSS driver i sold my nvidia card.

    ok from now im using latest git from mesa/ati driver

    so far :
    XV tear free as never seen before, i can multitask and my 1080p h264 videos play like nothing is running is beautyful and far better than fglrx.

    EXA. i feel it super duper snapy, no artifacts at all, kde 4.3.0. so happy here too

    Mesa well not working for me. aka my pciid is still missing from DRM/DRI/MESA (4850x2 pciid is 0x9443), as you can see i could patch the pciid in drm module already. but mesa in the other hand is giving me a hard time.

    i change my pciid in some files inside the radeon/r700 dri driver but still dont activate so like last time i tried im sure im missing a file where my pciid is lost.

    so someone can post here the list of files to modificate to get my pciid included.

    btw im using latest mesa git source pkg from xorg edgers PPA

  • bridgman
    replied
    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.

    Leave a comment:


  • nhaehnle
    replied
    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.

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:


  • nanonyme
    replied
    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.

    Leave a comment:


  • forum1793
    replied
    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

    Leave a comment:


  • forum1793
    replied
    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?

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:


  • pvtcupcakes
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:

Working...
X