Page 2 of 11 FirstFirst 1234 ... LastLast
Results 11 to 20 of 103

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

  1. #11
    Join Date
    Dec 2007
    Posts
    91

    Default

    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 ?

  2. #12
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,577

    Default

    Quote 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)

  3. #13
    Join Date
    Apr 2008
    Location
    A Coruņa (Spain)
    Posts
    100

    Default

    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.

  4. #14
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,577

    Default

    Quote 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.

  5. #15
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    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.

  6. #16
    Join Date
    Jul 2008
    Posts
    208

    Default

    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

  7. #17
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    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.

  8. #18
    Join Date
    Oct 2008
    Posts
    81

    Default

    What exactly was implemented in kernel 2.6.30? Kernel modesettings?

  9. #19
    Join Date
    Jun 2009
    Location
    Chicago, Illinois
    Posts
    36

    Default

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

  10. #20
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    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 at 12:27 AM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •