Announcement

Collapse
No announcement yet.

ATI R600/700 OSS 3D Driver Reaches Gears Milestone

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

  • #61
    Originally posted by tball View Post
    Aah I see.
    But I shouldn't try this on a 2.6.30 kernel?
    Not if you want it to work

    AFAIK the next step on the drm side would be to get it synced with the latest kernel code in preparation for merging it upstream. That probably means skipping over some of the kernel versions between 2.6.28 and 2.6.31.

    Comment


    • #62
      Originally posted by bridgman View Post
      Not if you want it to work

      AFAIK the next step on the drm side would be to get it synced with the latest kernel code in preparation for merging it upstream. That probably means skipping over some of the kernel versions between 2.6.28 and 2.6.31.
      Actually 2.6.29 and 2.6.30 run glxgears just the same as 2.6.28 for me. (as we all know, r6xx-r7xx-3d DRM requires a bit of patching to compile on 2.6.30) I managed to get all three to reproducably lockup with it though. I first started glxgears, then Firefox and it lockups.
      Edit: another user said he's getting the same lockup with Xv so might be related to EXA.
      Last edited by nanonyme; 07-16-2009, 08:12 PM.

      Comment


      • #63
        First of all, great work, this is very exciting.

        Now let me see if I understand the current state.

        - you need the latest drm (master), newer than the one that went into 2.6.31 kernel. A merge with the kernel is planned
        - you need the latest mesa (r600-rewrite branch). A merge with the master branch is currently being worked on

        So, the prospect is that soon we'll be able to install a stock kernel and, with recent enough stock Mesa, get glxgears on r600/r700?

        Comment


        • #64
          Originally posted by pingufunkybeat View Post
          - you need the latest drm (master), newer than the one that went into 2.6.31 kernel. A merge with the kernel is planned
          You need kernel modules from agd5f's r6xx-r7xx-3d drm branch and libdrm seems so far to be a free choice, drm master appears to be fine for that. Just have to be a bit careful before the r6xx-rewrite merge into Mesa master if you have libdrm with --enable-radeon-experimental-api since r6xx-rewrite is not all the time with sync with master until then. (and the API might change)
          Rephrase: don't compile libdrm with --enable-radeon-experimental-api unless you have a good reason to.
          Edit: "A merge with the master branch is currently being worked on" is an optimistic way imo to talk of r6xx-rewrite since currently what's being worked on is the implementation for r6xx-rewrite itself. :3 Developers probably have some kind of milestones for the functionality that it has to pass before they actually want to merge. (and they'll make sure the merge won't break any other drivers)
          Last edited by nanonyme; 07-16-2009, 08:08 PM.

          Comment


          • #65
            Thanks for the clarification.

            I guess I got too optimistic after reading "Alex just merged the last few weeks of changes from master into r6xx-rewrite (in preparation for merging r6xx-rewrite back into master)"

            Comment


            • #66
              Originally posted by pingufunkybeat View Post
              I guess I got too optimistic after reading "Alex just merged the last few weeks of changes from master into r6xx-rewrite (in preparation for merging r6xx-rewrite back into master)"
              Well, that's probably the reason for the recent sync, yes. I wouldn't read too much into the syncs, keeping r6xx-rewrite and master close together is smart since it makes the eventual merge easier but the developers only merge when they feel the code is ready enough. (I could always be wrong and they could merge the code immediately, I'm no mind-reader; all I'm saying reading between developers' lines isn't a good idea)
              Last edited by nanonyme; 07-16-2009, 08:37 PM.

              Comment


              • #67
                Originally posted by nanonyme View Post
                Actually 2.6.29 and 2.6.30 run glxgears just the same as 2.6.28 for me. (as we all know, r6xx-r7xx-3d DRM requires a bit of patching to compile on 2.6.30) I managed to get all three to reproducably lockup with it though. I first started glxgears, then Firefox and it lockups. Edit: another user said he's getting the same lockup with Xv so might be related to EXA.
                Nanonyme, was the lockup on 2.6.28 with the drm code straight from agd5f's repo, or was that with the patches for 2.6.30 already in ?

                There does seem to be some kind of interference between EXA and 3D, more so than between Xv and 3D. Best guess is that EXA is setting some state which 3D is not. Unfortunately there's a lot of state info to compare.

                We do hope to merge the mesa code into master as soon as we can be confident that it won't impact existing drivers. It's not like radeon-rewrite, where the new code replaced existing code that people were already using so the new code had to be "comparable" to the old code in terms of functionality and stability; for 6xx/7xx the choices are running the new code or swrast so the bar is relatively low. IIRC MostAwesomeDude's 3xx-5xx Gallium code went in as soon as there was confidence that it wouldn't break the builds, which I thought made sense.

                The bar will be quite a bit higher for merging drm, since we have the added requirement of being pretty confident the API between client and DRM will be able to stay stable from that point on. That means most of the important functionality will have to have been tested and verified, at least enough to know that the drm ioctls can be frozen.
                Last edited by bridgman; 07-16-2009, 09:12 PM.

                Comment


                • #68
                  Alex's last changes for 780g did help with glxgears.

                  Current test using slackware64-current with qt4+/kde4+

                  I still get a complete black screen (entire monitor) but when moving the mouse and clicking, the screen comes back, and I can see the familiar gears spinning. If I click on the glxgears window the complete black screen toggles back.

                  If I grab any window and move it or leave it even partially over the glxgears window, screen corruption below the glxgears window occurs. Closing the gears window and clicking on the corrupt area makes it go away.

                  Code:
                  bash-3.1$ glxgears
                  IRQ's not enabled, falling back to busy waits: 2 18
                  139 frames in 5.0 seconds = 27.706 FPS
                  142 frames in 5.0 seconds = 28.277 FPS
                  190 frames in 5.0 seconds = 37.948 FPS
                  198 frames in 5.0 seconds = 39.402 FPS
                  Devs you're doing great.
                  Last edited by forum1793; 07-16-2009, 09:06 PM.

                  Comment


                  • #69
                    Another observation.

                    I'm getting around 28 fps. But if I cover some of the glxgears window the fps shoots up. If I totally cover it the number goes up to >1000 fps.

                    Question: what options should we be using for xorg.conf
                    This is my current relevant section:
                    Code:
                    Section "Device"
                    	Identifier  "RadeonVid"
                    	Driver "radeon"
                    	Option "AccelMethod"  "exa"
                    #	Option "EXANoComposite" "true"
                    #	Option "EXANoUploadToScreen"
                    #	Option "EXANoDownloadFromScreen"
                    #	Option "MigrationHeuristic" "greedy"
                    		
                    EndSection
                    I'll try in a bit with some alternatives.

                    Comment


                    • #70
                      Originally posted by bridgman View Post
                      Nanonyme, was the lockup on 2.6.28 with the drm code straight from agd5f's repo, or was that with the patches for 2.6.30 already in ?
                      Iirc it was straight from repo but never hurts to check again.

                      Originally posted by bridgman View Post
                      We do hope to merge the mesa code into master as soon as we can be confident that it won't impact existing drivers. It's not like radeon-rewrite, where the new code replaced existing code that people were already using so the new code had to be "comparable" to the old code in terms of functionality and stability; for 6xx/7xx the choices are running the new code or swrast
                      I'd probably still consider swrast to be the better choice for casual users before the memcpy issue gets sorted out and replaced with something in the DRM and this EXA/Xv vs OpenGL confrontation ends up in at least a ceasefire, preferably a peace. :3

                      Comment


                      • #71
                        Originally posted by forum1793 View Post
                        I'm getting around 28 fps. But if I cover some of the glxgears window the fps shoots up. If I totally cover it the number goes up to >1000 fps.

                        I'll try in a bit with some alternatives.
                        That's a waste of time, the performance thing is a known issue and will be resolved in time. Currently it's not possible to get high framerates out of the driver when you actually render the window instead of covering it.

                        Comment


                        • #72
                          Originally posted by nanonyme View Post
                          Decided to note it here so it gets documented: if you're having a fullscreen black screen with Fedora 11 when running glxgears with the r600 Mesa driver, try instead running progs/demos/gears from your Mesa build tree. (assuming you compiled the demos) It's the exact same program, just a newer version. It seems Fedora 11 got shipped with a glxgears that features a bit odd with at least this particular driver.
                          I just saw this and tried it (progs/demos/gears). The screen blanking does not occur but the corruption when windows overlap the gears window still does. Thanks.

                          Comment


                          • #73
                            Originally posted by forum1793 View Post
                            I just saw this and tried it (progs/demos/gears). The screen blanking does not occur but the corruption when windows overlap the gears window still does. Thanks.
                            As bridgman swiftly pointed out, glxgears is not the same as gears; since GLX is short for "OpenGL Extension to the X Window System", it's likely the rendering somehow passes through the X server as he said. Something along the way apparently breaks with that call path.
                            It'd be a very wild guess that but I'd suspect the screen corruption might be related to this EXA/Xv interference with OpenGL too since window managers tend to use EXA for acceleration. Would probably have to manually disable all EXA hooks and see whether the corruption and lockups disappear.

                            Comment


                            • #74
                              I was trying to find out a way to cleanly set EXA off since I couldn't find the hooks in documentation. When I tried compiling radeon with ./configure --disable-exa, it very much removed it, even xvinfo stopped giving anything. The intriguing thing is glxgears and every other OpenGL program stopped working too. The switch is a bit invasive so would of course have to find out what exactly it disables (it apparently unsets USE_EXA which is abundant in the sources) but it frighteningly looks like current OpenGL implementation was dependent on EXA. So it might be somewhat more than one state setup from EXA side that you'd actually need to setup the r600 Mesa driver properly.
                              Edit: Though what kind of a moron would be running OpenGL on an X server without EXA support. :3 (hint: me)
                              Last edited by nanonyme; 07-17-2009, 09:30 AM.

                              Comment


                              • #75
                                The black screen issue happens with both progs/xdemos/glxgears and progs/demos/gears here (HD 3300).

                                So I tried some other programs in the progs/demos directory. And reflect was the only one that didn't show this issue. I compared reflect with other programs and I noticed that this was the only one using the stencil buffer.

                                So, the black screen issued can be fixed (at least for me) by modifying gears and glxgears in the following way:

                                Code:
                                diff --git a/progs/xdemos/glxgears.c b/progs/xdemos/glxgears.c
                                index bc84ee3..6432fd2 100644
                                --- a/progs/xdemos/glxgears.c
                                +++ b/progs/xdemos/glxgears.c
                                @@ -489,6 +489,7 @@ make_window( Display *dpy, const char *name,
                                                      GLX_BLUE_SIZE, 1,
                                                      GLX_DOUBLEBUFFER,
                                                      GLX_DEPTH_SIZE, 1,
                                +                     GLX_STENCIL_SIZE, 1,
                                                      None };
                                    int stereoAttribs[] = { GLX_RGBA,
                                                            GLX_RED_SIZE, 1,

                                Code:
                                diff --git a/progs/demos/gears.c b/progs/demos/gears.c
                                index 6016162..805dd79 100644
                                --- a/progs/demos/gears.c
                                +++ b/progs/demos/gears.c
                                @@ -386,7 +386,7 @@ visible(int vis)
                                 int main(int argc, char *argv[])
                                 {
                                   glutInit(&argc, argv);
                                -  glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE);
                                +  glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE | GLUT_STENCIL);
                                 
                                   glutInitWindowPosition(0, 0);
                                   glutInitWindowSize(300, 300);
                                So, I think this might have something to do with the stencil buffer?
                                Last edited by Nils; 07-17-2009, 10:13 AM.

                                Comment

                                Working...
                                X