Announcement

Collapse
No announcement yet.

AMD Releases Additional R600 GPU Programming Documentation

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

  • #16
    Originally posted by bridgman View Post
    >>It's the 2D/3D stuff that we're all craving out here...

    Just wanted to remind everyone that the 2d acceleration on the RS690 and the R5xx family is pretty much unchanged from earlier chips. The 2d acceleration code in the radeon driver is actually running on R5xx parts today.

    3d acceleration on RS690 is also unchanged from the 4xx parts other than the lack of vertex shaders.
    That makes me wonder why there is no (almost complete in functions) open source driver for RS690 uptill now? Parts are more or less ready and what's left is to combine them, so what's stoping the devs ? I mean it could have been done along the reverse engineering of r4xx chips.

    and BTW radeonhd is for r5xx r6xx cards if RS690 is so much closer to r4xx then it does make sence to put it into radeon (r2xx r3xx r4xx) driver instead. I'm a bit confused about why it's in the radeonhd dirver now.
    Last edited by val-gaav; 01-05-2008, 08:08 AM.

    Comment


    • #17
      Originally posted by val-gaav View Post
      That makes me wonder why there is no open source driver for RS690 uptill now? Parts are more or less ready and what's left is to combine them, so what's stoping the devs ?

      and BTW radeonhd is for r5xx r6xx cards if RS690 is so much closer to r4xx then it does make sence to put it into radeon (r2xx r3xx r4xx) driver instead ? I'm a bit confused about it now.
      well, to put it in simple ways:
      - radeonhd is totally developed from the source with the addition of some working code from radeon parts.
      - radeon code has been written in its majority from reverse engineering the old fglrx code.

      the thing that board are similar doesn't imply that they're the same and john pointed out some differences. the main problem is that radeonhd is developed entirely on the new r600 series and works with some older r500 that are similar to the r600. the radeonhd could work also on other chips but the devs don't know about it since they never tried testing it on r300 or 400 for example. but for the moment it's likely that it won't work on these boards without harm.
      the radeon branch instead is working for boards till r500 and is adding various support for newer features and boards. it's known that with time we'll have just one driver but for now the 2 codes from the 2 drivers are different and until the radeonhd doesn't finishes its code for the new boards i don't think that it will converge into the radeon, while the radeon branch will continue to increase its features, stability and speed for the older cards also through utilities from radeonhd and specs from amd and one day it will absorb radeonhd, but i don't see this happening this year.

      Comment


      • #18
        What about MPEG2 acceleration? Some of us don't give a damn about gaming or 3D effects, but faster video decoding would be nice...
        Last edited by highlandsun; 01-06-2008, 04:25 AM.

        Comment


        • #19
          Originally posted by TechMage89 View Post

          Bridgman, one question though. I've taken a look at the 2d acceleration bits in the radeon driver, and although XAA does work on my x1600, the code looks incomplete and hacky, and EXA isn't functional (at reasonable speeds) at all. Large parts of XAA aren't accelerated, or only partially so. I'm wondering if there is some original 2d engine documentation I can refer to, because I don't think the radeon driver is using all of the card's functionality.

          As for EXA, I'm not sure what's causing the issue, I need to try some performance profiling.
          What do you mean looks incomplete and hacky? I assume you are basing this on your years of experience writing XAA/EXA drivers? or just on the fact that you can't understand the codepaths?

          XAA is functionally complete in that it provides accel for anything it can.

          EXA is still a work in progress and the missing bit is Composite support which actually requires using the 3D engine not the 2D engine. We only support Composite on r100/r200 so far and I'd like to add r300 support at some point. R500 needs some info on the fragment shader pipeline to happen.

          XAA also has some support for composite operations but we might not bother implementing that (maybe someone will, they mainly make gnome-terminal go faster).

          Really EXA isn't a great final solution as-is, we require a unified memory manager like TTM to really make it shine. Otherwise we end up with the current texture/pixmap VRAM split etc...

          Comment


          • #20
            Originally posted by val-gaav View Post
            That makes me wonder why there is no (almost complete in functions) open source driver for RS690 uptill now? Parts are more or less ready and what's left is to combine them, so what's stoping the devs ? I mean it could have been done along the reverse engineering of r4xx chips.

            and BTW radeonhd is for r5xx r6xx cards if RS690 is so much closer to r4xx then it does make sence to put it into radeon (r2xx r3xx r4xx) driver instead. I'm a bit confused about why it's in the radeonhd dirver now.

            rs690 modesetting is the same as the r500 parts, so it needs atombios or radeonhd support to set modes. the 3D engine is like the 3D engine on rs480, but there is also a large chunk of work just programming the memory controller on these chips. Setting up the memory controller is tricky (maybe atombios will make it easier).

            Once the memory controller is working, the current Mesa r300 driver should work on top of it all fine, however the current Mesa r300 driver doesn't fully support "vertex shader"-less cards, googleearth and many games work, compiz however has resisted fixing, I'd hope to remedy this situation since I wrote the current "vertex shader"-less codepaths, but time as ever is the enemy.

            Comment


            • #21
              Originally posted by bridgman View Post
              2d acceleration on R6xx parts and 3d acceleration on 5xx/6xx parts are next on the documentation list.
              Excellent.

              It'll be good to see how this evolves. I'm actually quite interested in seeing how it all happens. When I get more time I think I'll start contributing to the driver (even though ewwww plain old c )

              Comment


              • #22
                Originally posted by TechMage89 View Post
                Bridgman, one question though. I've taken a look at the 2d acceleration bits in the radeon driver, and although XAA does work on my x1600, the code looks incomplete and hacky, and EXA isn't functional (at reasonable speeds) at all. Large parts of XAA aren't accelerated, or only partially so. I'm wondering if there is some original 2d engine documentation I can refer to, because I don't think the radeon driver is using all of the card's functionality.

                As for EXA, I'm not sure what's causing the issue, I need to try some performance profiling.
                The manual that came with the R200 info seemed pretty good and gives a pretty good intro to programming the parts. I'm going to try to re-release that some time soon. I was flipping through it over the weekend (while ice fishing ) trying to figure out how much work it would take to bring it up to date for 5xx if not 6xx.

                re: EXA, there seems to be some agreement that EXA may need better memory management to work well. I'm not 100% sure of that but it does seem likely.

                re: XAA, I have been told by a couple of devs that a lot of the benefit comes from accelerating just a few functions. At XDS there was some talk about mismatches between the current 2d acceleration APIs and the functions which are actually used heavily -- I think the comment was "XAA accelerates all the stuff that nobody uses any more".

                Comment


                • #23
                  Originally posted by airlied View Post
                  What do you mean looks incomplete and hacky?
                  Yow... Guess you told him Dave. Good to see you around here- *I* don't think the work's hacky or kludgy.

                  Comment


                  • #24
                    Originally posted by Ze.. View Post
                    When I get more time I think I'll start contributing to the driver (even though ewwww plain old c )
                    What's wrong with a bit of "C" coding? C++ is nice, but it's got some small issues in it's use with drivers. To be sure, it's not as bad as some make it out to be, but it's easier in some ways to do very, very brain-dead things in C++ when you're talking about code for the driver space on an OS- which is a part of why the Linux kernel crowd vehemently oppose the use thereof.

                    As it stands, I've got a couple of things to get off my plate before I can consider doing some stuff- but it's on my shorter list of things to do.

                    Comment


                    • #25
                      Ok, ok, maybe the language I used was a little too strong, especially given the fact I don't have a lot of experience with C, but when I see lots of comments like "we can't fully accelerate this operation" or "someone needs to find a better way to do this" I do begin to suspect that the code needs some work. (those are rough quotes, I haven't got the code in front of me)

                      Granted, maybe the operations aren't that important, so no one thought them worth the effort to fix, but I'm afraid I'm a bit of a perfectionist .

                      Also, I'm not entirely sure what's a silicon problem and what's a coding problem (mainly because I haven't got the docs.)

                      I'm an object-oriented programmer by training, so when I try to understand a large amount of code, I try to compartmentalize things, but that doesn't seem to work too well on the radeon driver.

                      Maybe I've bitten off a bit more than I can chew and should just go back to application programming .

                      At any rate, I regarding EXA, I don't just mean that the performance isn't that good on my card, I mean it's unusable.

                      Comment


                      • #26
                        The radeon ddx was written with documentation or directly from ati code drops. Really the only things that were reverse engineered were the XPRESS (RS480) chips and that was more trial and error than reverse engineering. The 3D (mesa) code is another matter. r100 and r200 were written with documentation, r300 (covers r400 as well) was reverse engineered.

                        The 2D accel code is solid. XAA exposes just about every feature of the 2D engine (fills, blits, image transfers, lines, color expansion, etc.), however, no modern toolkit really uses 2D feature other than fills and blits. As such the only EXA hooks that use the 2D engine are fills, blits, and image transfers. The EXA composite hooks require the 3D engine, so it is a lot more work to get running. We have full support for r100/r200 (in fact it was the HW we used for EXA development since these chips had the best documentation available).

                        Comment


                        • #27
                          My bad, it looks like most of the non-accelerating stuff is trivial. And hardware limited

                          Another thought: if the 2d engine is no longer included in the r600, does using the 3d engine for 2d acceleration reduce performance over older cards? Would 2d performance be better? If so, could the same method also be used for older cards that don't require it (eg. R500)?

                          Comment


                          • #28
                            Originally posted by TechMage89 View Post
                            My bad, it looks like most of the non-accelerating stuff is trivial. And hardware limited

                            Another thought: if the 2d engine is no longer included in the r600, does using the 3d engine for 2d acceleration reduce performance over older cards? Would 2d performance be better? If so, could the same method also be used for older cards that don't require it (eg. R500)?
                            You could use the 3D engine for blits, etc. on any of the older cards, it's just a lot more complicated to program. There's a slight bit more overhead using the 3D engine as more state programming is involved, but it's probably pretty negligible in practice. Plus with modern composited desktops you want to use transforms and blends anyway which are not available on the 2D engine. Those come for free (more or less) when using 3D.

                            Comment


                            • #29
                              In general the 3d engine is faster these days. That wasn't always the case a few generations ago.

                              Comment


                              • #30
                                "compiz has resisted fixing"?

                                There are far simpler programs than Compiz that have trouble with the Mesa R300 driver. Try the "rubik" hack from xscreensaver, for example...

                                And I'm not sure if this message is trying to warn me of a driver bug or a hardware limitation either:
                                File r300_texstate.c function r300SetTexImages line 301
                                DXT 3/5 suffers from multitexturing problems!
                                Has any of the new documentation allowed for the R300 driver to be enhanced further without reverse engineering?

                                Comment

                                Working...
                                X