Announcement

Collapse
No announcement yet.

AMD Releases Additional R600 GPU Programming Documentation

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

  • #31
    What info is needed to implement e.g. XvMC support?

    Comment


    • #32
      Originally posted by chrisr View Post
      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:

      Has any of the new documentation allowed for the R300 driver to be enhanced further without reverse engineering?
      Well as a programmer who did spend quite bit of time on r300 i would say that current r300 driver is dead end. The code is ugly, wrongly designed and with lot of hack all around. Truly what is needed is a rewrite and i see gallium as an opportunity to do so and do it right from the beginning. Unfortunately we are in a business with short time frame and i am sure more manpower will be put into patching r300 to have somethings working as soon as possible.

      Regarding the problem you face the message is pretty explicit: multi-texturing is broken with dxt compressed texture.

      Comment


      • #33
        Originally posted by airlied View Post
        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.
        Thanks for the clarification on this. Now I understand why rs690 is in the radeonhd driver.

        Comment


        • #34
          Originally posted by highlandsun View Post
          What info is needed to implement e.g. XvMC support?
          Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.
          Test signature

          Comment


          • #35
            Originally posted by bridgman View Post
            Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.
            Is the schedule of each documentation release, defined by the progress of radeonhd ?
            You said that tcore was almost ready to publish but you needed to keep it for some reason.
            My questions is do we need to wait for the radeonhd driver to take complete advantage of the doc before a new release of doc happens ?

            Comment


            • #36
              Well as a programmer who did spend quite bit of time on r300 i would say that current r300 driver is dead end. The code is ugly, wrongly designed and with lot of hack all around.
              well, since this time more documentation will [hopefully] be available, i'd say a total rewrite is not such a bad idea.

              i didn't think that the driver is such a mess, though. it "just works" for me all the time.

              Comment


              • #37
                Originally posted by lucky_ View Post
                Is the schedule of each documentation release, defined by the progress of radeonhd ? You said that tcore was almost ready to publish but you needed to keep it for some reason.
                My questions is do we need to wait for the radeonhd driver to take complete advantage of the doc before a new release of doc happens ?
                When we are preparing (or, in the case of tcore, sanitizing) information for release we give it to the radeonhd developers when we think it is "pretty much the same as what we are going to release publicly" but before the final review. The final review and cleanup takes a variable amount of time depending on what we find in the review. In the case of tcore we found more references to unreleased ASICs and parts from other non-PC business units than I initially expected so we're still cleaning it up.

                This is why I'm not publishing a schedule for documentation releases, just a sequence and a rough idea of when things will happen. Until we actually get deep into the reviews and discussions we don't really know how long each activity will take. Modelling effort requirements (and hence schedule) for documentation cleanup is actually proving to be harder than modelling and scheduling software development, which is another interesting surprise. It's certainly more like modifying a large legacy code base you have never seen before than designing and writing code from scratch.
                Last edited by bridgman; 08 January 2008, 06:37 PM.
                Test signature

                Comment


                • #38
                  Explicit, yes. Clear? No.

                  Originally posted by glisse View Post
                  Regarding the problem you face the message is pretty explicit: multi-texturing is broken with dxt compressed texture.
                  So is that "broken" as in "It's a bug in the code, and we can fix it", or as in "It's a bug and we don't know how to fix it"? Or maybe "The particular hardware doesn't support that functionality"? Or perhaps even "The hardware should support that functionality, but doesn't for some unknown reason."?

                  So many possibilities...

                  Comment


                  • #39
                    Originally posted by chrisr View Post
                    So is that "broken" as in "It's a bug in the code, and we can fix it", or as in "It's a bug and we don't know how to fix it"? Or maybe "The particular hardware doesn't support that functionality"? Or perhaps even "The hardware should support that functionality, but doesn't for some unknown reason."?

                    So many possibilities...
                    It is r300 driver limitation.

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.
                      Thanks for the response. I'll keep an eye out for those milestones.

                      Comment

                      Working...
                      X