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

  • #11
    Ok, because even if it looks like a long journey.
    I certainly will give it a shot during the holidays hehe.
    Is it worth writing a script to do the whole thing ?
    And what about an update-thewholebunch option ?

    Comment


    • #12
      Originally posted by lucky_ View Post
      And is it worth the run ?
      What is it's status ?
      Status is it doesn't really do much. It's still in quite early development phase. And if you want to actually use it for running OpenGL, no, it's not worth it yet. It's only worth for checking out if you're interested in seeing if the initial code breaks in the same way as yesterday or in new interesting ways. (Seriosly speaking, the code is still mostly only useful if you're a developer. It's still missing a lot)

      Comment


      • #13
        I got it compiled using ebuilds (the problem I posted before with pkgconfig was because the ebuild was not using the r6xx-r7xx-3d branch).

        When I launch glxgears, I get a kernel oops (or something similar). If I try a second time, the system freezes. So obviously not quite ready yet :P. I'll post the trace tomorrow, in case it helps.

        Comment


        • #14
          Originally posted by Fran View Post
          I got it compiled using ebuilds (the problem I posted before with pkgconfig was because the ebuild was not using the r6xx-r7xx-3d branch).

          When I launch glxgears, I get a kernel oops (or something similar). If I try a second time, the system freezes. So obviously not quite ready yet :P. I'll post the trace tomorrow, in case it helps.
          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.

          Comment


          • #15
            Yeah, this is roughly where we were with driver bring-up when we decided to jump across to the radeon-rewrite code base and define a new API for the mesa-to-drm interface.

            There is code in the driver to do a lot more than glxgears, but we need to keep slogging through bringup work for a bit longer.

            Comment


            • #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

                      Working...
                      X