Announcement

Collapse
No announcement yet.

Getting Open Source 3D graphics on R6XX/R7XX cards (NO FGLRX)

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

  • #16
    1. Does this work with 2.6.29 kernel?

    2. Does this work with kde4.2, which seems to have qt4?

    3. Does this work with 64 bit?

    I'm trying all three and have not gotten any 3D with hd3200.

    With radeon (ati) running, glxinfo or glxgears gives:
    Code:
    Error: couldn't get an RGB, Double-buffered visual

    Comment


    • #17
      The current drm code seems to work best with 2.6.27 and 2.6.28 right now. I have seen problems reported with 2.6.29 and 64-bit. Not sure whether the devs are mostly working in 32- or 64-bit, will ask. In terms of working with KDE, all I can say is "I would be really surprised if it did".

      The devs are going through the bringup activity now, starting with the basic Redbook tests and fixing each of those first.

      Comment


      • #18
        What exactly was implemented in kernel 2.6.30? Kernel modesettings?

        Comment


        • #19
          Kernel modesettings for Radeon was never actually implented in the upstream 2.6.30 kernel source.

          Comment


          • #20
            Yep. What went into 2.6.30 was the drm calls used by the X server for EXA and Xv acceleration on 6xx/7xx.

            Direct rendering clients (eg Mesa, the 3D driver) use a different set of API calls; those are not yet supported in the kernel tree. Not sure if they will make it into 2.6.31 or not; it depends on 3D driver progress. Until the 3D driver is at a point where we think the mesa-to-drm API can be frozen it is not considered appropriate to put the API support into the kernel tree. This seems like a rule which could use a tiny bit of fine-tuning
            Last edited by bridgman; 06-06-2009, 12:27 AM.

            Comment


            • #21
              Originally posted by nanonyme View Post
              Better try for simpler tests like redbook hello. It's available under progs/redbook under your Mesa source tree and probably got compiled along with your Mesa sources. It's a simple program that draws a white rectangle on a black background. Until it works properly, probably a waste of time running glxgears.
              Nope, same oops with redbook hello:
              Code:
              Jun  6 11:30:58 quad klogd: PGD 13a9d5067 PUD 13aa2b067 PMD 0
              Jun  6 11:30:58 quad klogd: CPU 0
              Jun  6 11:30:58 quad klogd: Modules linked in: bttv ir_common videobuf_dma_sg videobuf_core btcx_risc tveeprom af_packet coretemp it87 hwmon_vid hwmon usbhid hid tuner snd_hda_codec_realtek snd_hda_intel tda9887 tuner_simple snd_hda_codec tuner_types snd_pcm v4l2_common videodev snd_timer v4l2_compat_ioctl32 sr_mod uhci_hcd snd ehci_hcd r8169 cdrom usbcore evdev soundcore snd_page_alloc mii [last unloaded: tveeprom]
              Jun  6 11:30:58 quad klogd: Pid: 2231, comm: hello Not tainted 2.6.30-rc8-radeon #2 G33-DS3R
              Jun  6 11:30:58 quad klogd: RIP: 0010:[<ffffffff804e04d3>]  [<ffffffff804e04d3>] __mutex_lock_slowpath+0xb3/0x1b0
              Jun  6 11:30:58 quad klogd: RSP: 0018:ffff88013a91fc60  EFLAGS: 00010246
              Jun  6 11:30:58 quad klogd: RAX: 0000000000000000 RBX: ffff88013ea74e3c RCX: ffff88013a91fdc8
              Jun  6 11:30:58 quad klogd: RDX: ffff88013c5f0240 RSI: ffff88013a91fdc8 RDI: ffff88013ea74e3c
              Jun  6 11:30:58 quad klogd: RBP: ffff88013ea74e38 R08: ffffffff8040a960 R09: 00007f8bddca0720
              Jun  6 11:30:58 quad klogd: R10: 000000000000013f R11: 0000000000000246 R12: ffffffffffffffff
              Jun  6 11:30:58 quad klogd: R13: ffff88013ea74e40 R14: 0000000000000000 R15: ffff88013fa7d750
              Jun  6 11:30:58 quad klogd: FS:  00007f8bddca0720(0000) GS:ffff880028022000(0000) knlGS:0000000000000000
              Jun  6 11:30:58 quad klogd: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
              Jun  6 11:30:58 quad klogd: CR2: 0000000000000000 CR3: 000000013aa82000 CR4: 00000000000006e0
              Jun  6 11:30:58 quad klogd: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
              Jun  6 11:30:58 quad klogd: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
              Jun  6 11:30:58 quad klogd: Process hello (pid: 2231, threadinfo ffff88013a91e000, task ffff88013fa7d750)
              Jun  6 11:30:58 quad klogd:  ffff88013ea74e40 000000004a2a3752 ffff88013fbea500 0000000000000dbf
              Jun  6 11:30:58 quad klogd:  RSP <ffff88013a91fc60>
              Jun  6 11:30:58 quad klogd: ---[ end trace f64472c6cfd2333f ]---
              Jun  6 11:30:58 quad klogd: note: hello[2231] exited with preempt_count 3
              Jun  6 11:30:58 quad klogd: Modules linked in: bttv ir_common videobuf_dma_sg videobuf_core btcx_risc tveeprom af_packet coretemp it87 hwmon_vid hwmon usbhid hid tuner snd_hda_codec_realtek snd_hda_intel tda9887 tuner_simple snd_hda_codec tuner_types snd_pcm v4l2_common videodev snd_timer v4l2_compat_ioctl32 sr_mod uhci_hcd snd ehci_hcd r8169 cdrom usbcore evdev soundcore snd_page_alloc mii [last unloaded: tveeprom]
              Jun  6 11:30:58 quad klogd: Pid: 2231, comm: hello Tainted: G      D    2.6.30-rc8-radeon #2
              Jun  6 11:30:58 quad klogd: Call Trace:
              Jun  6 11:30:58 quad klogd:  [<ffffffff804df789>] ? thread_return+0x16c/0x683
              Jun  6 11:30:58 quad klogd:  [<ffffffff8023a72e>] ? vprintk+0x37e/0x420
              Jun  6 11:30:58 quad klogd:  [<ffffffff804dfcb8>] ? schedule+0x18/0x40
              Jun  6 11:30:58 quad klogd:  [<ffffffff802359fc>] ? __cond_resched+0x1c/0x50
              Jun  6 11:30:58 quad klogd:  [<ffffffff804dfdc7>] ? _cond_resched+0x37/0x40
              Jun  6 11:30:58 quad klogd:  [<ffffffff80284451>] ? unmap_vmas+0x801/0x980
              Jun  6 11:30:58 quad klogd:  [<ffffffff802897ca>] ? exit_mmap+0xda/0x1a0
              Jun  6 11:30:58 quad klogd:  [<ffffffff80237295>] ? mmput+0x25/0xc0
              Jun  6 11:30:58 quad klogd:  [<ffffffff8023b74e>] ? exit_mm+0xfe/0x140
              Jun  6 11:30:58 quad klogd:  [<ffffffff8023d7d6>] ? do_exit+0x676/0x6f0
              Jun  6 11:30:58 quad klogd:  [<ffffffff8023a093>] ? release_console_sem+0x1a3/0x1f0
              Jun  6 11:30:58 quad klogd:  [<ffffffff8020f922>] ? oops_end+0x72/0xa0
              Jun  6 11:30:58 quad klogd:  [<ffffffff80225fea>] ? no_context+0xfa/0x270
              Jun  6 11:30:58 quad klogd:  [<ffffffff802c0ba9>] ? block_write_end+0x39/0x90
              Jun  6 11:30:58 quad klogd:  [<ffffffff802262b5>] ? __bad_area_nosemaphore+0x155/0x220
              Jun  6 11:30:58 quad klogd:  [<ffffffff80319883>] ? __ext4_journal_stop+0x33/0x90
              Jun  6 11:30:58 quad klogd:  [<ffffffff8030b256>] ? ext4_da_write_end+0xe6/0x2d0
              Jun  6 11:30:58 quad klogd:  [<ffffffff8030f7d0>] ? ext4_da_get_block_prep+0x0/0x1f0
              Jun  6 11:30:58 quad klogd:  [<ffffffff804e251f>] ? page_fault+0x1f/0x30
              Jun  6 11:30:58 quad klogd:  [<ffffffff8040a960>] ? radeon_cs_ioctl+0x0/0x450
              Jun  6 11:30:58 quad klogd:  [<ffffffff804e04d3>] ? __mutex_lock_slowpath+0xb3/0x1b0
              Jun  6 11:30:58 quad klogd:  [<ffffffff804e035a>] ? mutex_lock+0x1a/0x40
              Jun  6 11:30:58 quad klogd:  [<ffffffff8040a990>] ? radeon_cs_ioctl+0x30/0x450
              Jun  6 11:30:58 quad klogd:  [<ffffffff80246027>] ? block_all_signals+0x37/0xa0
              Jun  6 11:30:58 quad klogd:  [<ffffffff8026f71e>] ? generic_file_aio_write+0x7e/0xf0
              Jun  6 11:30:58 quad klogd:  [<ffffffff803d24a0>] ? drm_ioctl+0x140/0x3c0
              Jun  6 11:30:58 quad klogd:  [<ffffffff8030658b>] ? ext4_file_write+0x4b/0x160
              Jun  6 11:30:58 quad klogd:  [<ffffffff8040a960>] ? radeon_cs_ioctl+0x0/0x450
              Jun  6 11:30:58 quad klogd:  [<ffffffff8029bac2>] ? do_sync_write+0xe2/0x120
              Jun  6 11:30:58 quad klogd:  [<ffffffff802aa2f2>] ? vfs_ioctl+0x82/0xb0
              Jun  6 11:30:58 quad klogd:  [<ffffffff802aa3a8>] ? do_vfs_ioctl+0x88/0x560
              Jun  6 11:30:58 quad klogd:  [<ffffffff802aa8c9>] ? sys_ioctl+0x49/0x80
              Jun  6 11:30:58 quad klogd:  [<ffffffff8029c78e>] ? sys_write+0x4e/0x90
              Jun  6 11:30:58 quad klogd:  [<ffffffff8020b3eb>] ? system_call_fastpath+0x16/0x1b
              After that I still can use X, but if I try again with another demo, X hangs.

              (edit) I forgot: I'm using 2.6.30-rc8 patched with this. Maybe that's the cause.

              Comment


              • #22
                Try following the exact guide with the kernel source tarball given.

                Comment


                • #23
                  Nah, I don't like to pollute my system with custom compilations. I *always* use ebuilds so that the computer can be left in the exact same state it was before the tests; thanks to sandbox and collision-protect I know nothing else is touched during compilations or installations. A make install by hand with prefix=/usr can very easily bork a system (I do use my production system for these tests, I feel quite secure with portage taking care of things).

                  I'll simply wait until this can be tested in a 2.6.3X kernel. Or maybe I'll make an ebuild for agd5f's drm module, instead of using the in-kernel one in .30.

                  Comment


                  • #24
                    Originally posted by bridgman View Post
                    The current drm code seems to work best with 2.6.27 and 2.6.28 right now. I have seen problems reported with 2.6.29 and 64-bit. Not sure whether the devs are mostly working in 32- or 64-bit, will ask.
                    2.6.30 has a sysfs redesign which requires rewrite on quite a few kernel drivers including the DRM driver. (This leads to compilation issues with agd5f's DRM and an 2.6.30 kernel. I tried writing compat stuff to get it to work but it turned out to be Bloody Tricky (tm). Probably a good point to see after the 2.6.30 release whether or not it's enough for it to work to just solve the sysfs issue. Porting by breaking compatibility is semi-trivial since DRM in Linus' kernel tree already *is* compliant with the changes)
                    It seems to ~work on 2.6.29 (as in, it starts, rendering corruption, occasional hangups). I'm not a dev but I do all my testing with a 64-bit kernel.
                    Last edited by nanonyme; 06-06-2009, 08:09 AM.

                    Comment


                    • #25
                      Originally posted by Fran View Post
                      Nah, I don't like to pollute my system with custom compilations.
                      This is why --prefix exists. (Well, right. Apparently Neo told you to install under /usr. You should note that you don't have to as long as you pedantically install under the same prefix and make sure headers and libraries under the prefix are used in compiling and later on and tell OpenGL programs to load the right library with a variable. It's a bit more tricky but keeps your system clean)
                      Last edited by nanonyme; 06-06-2009, 08:00 AM.

                      Comment


                      • #26
                        Originally posted by Fran View Post
                        (edit) I forgot: I'm using 2.6.30-rc8 patched with this. Maybe that's the cause.
                        Put nomodeset in Grub kernel line on a KMS kernel or you'll get really weird behaviour.

                        Comment


                        • #27
                          Originally posted by nanonyme View Post
                          Put nomodeset in Grub kernel line on a KMS kernel or you'll get really weird behaviour.
                          Yeah, I was disabling modesetting. Anyway, after my last message I tried with 2.6.29 and x11-drm from agd5f and got the same results as you: corruption with some demos and a X freeze after a while.

                          Comment


                          • #28
                            I didn't know the correct enviornmental varibles to set so if anybody could state some exact examples on what to do when not installed to /usr that would be great!

                            edit: ^I have been asking that question everywhere for 2 years. Nobody never ever answers it.
                            Last edited by Neo_The_User; 06-06-2009, 12:11 PM.

                            Comment


                            • #29
                              Originally posted by Fran View Post
                              Nah, I don't like to pollute my system with custom compilations.
                              Since that's the *only* way to install a kernel in gentoo whether or not you use an ebuild, what's the problem?

                              Comment


                              • #30
                                Originally posted by Ant P. View Post
                                Since that's the *only* way to install a kernel in gentoo whether or not you use an ebuild, what's the problem?
                                I was talking about the "try following the exact guide" part. Obviously I don't have any problem with compiling my own kernels (in fact after that message I tried with 2.6.29 + custom x11-drm ebuild).

                                Comment

                                Working...
                                X