Announcement

Collapse
No announcement yet.

R600 Gallium3D Reorders Atom State Emission

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

  • R600 Gallium3D Reorders Atom State Emission

    Phoronix: R600 Gallium3D Reorders Atom State Emission

    The R600g patches for reworking the atom state emission ordering have landed, after having to infer the ordering sequence from the Catalyst binary blob command stream...

    http://www.phoronix.com/vr.php?view=MTE4MDk

  • #2
    Does that mean there'll be a fresh attempt at getting HyperZ to work?

    Comment


    • #3
      Originally posted by Chewi View Post
      Does that mean there'll be a fresh attempt at getting HyperZ to work?
      +1

      I think every r600 user would like to know the answer to this Q.

      Comment


      • #4
        I think there's going to be a big bust up between Jerome and Marek soon

        Comment


        • #5
          Originally posted by FireBurn View Post
          I think there's going to be a big bust up between Jerome and Marek soon
          What do you mean?

          On topic: Anything that can bump up the performance and features of the Radeon driver, im happy with. Kind of sucks that it may come down to a hardware bug.

          I remember the original thread involving HyperZ and a possible HW bug, but does anyone remember (or if he could post himself) if Bridgman mentioned if the bug was still in place? Like was this ONE generation of hardware that had a bug in it, or is it the type of thing where we'd need to code around this bug even now for the current generations like Southern Islands?

          Comment


          • #6
            Originally posted by Chewi View Post
            Does that mean there'll be a fresh attempt at getting HyperZ to work?
            Interesting. Also:
            Does this mean that there'll be a new attempt at getting HyperZ to work for the r300 driver?
            (That is one of the last things that would make that open source driver rather complete.)

            Comment


            • #7
              IIRC the original HyperZ "issue" was that on earlier parts there was a fixed size on-chip memory which was basically sufficient for a single app. At the time that was fine (the one app was the Windows game you were running) but on a modern Linux system that means the compositor gets HyperZ and the apps get nothing unless some really clever heuristics are added (and I'm not sure anyone felt this was a good use of time).

              Starting with (r600 ?) I believe the HyperZ implementation moved to more of a cache model and was shareable across apps, so has the potential to be useful in a composited environment. Something like that.

              The challenge of getting HyperZ, tiling, alignment and all the other bits working together in all the corner cases still remains though.

              Comment


              • #8
                I'm sure there are other issues.

                Originally posted by bridgman View Post
                IIRC the original HyperZ "issue" was that on earlier parts there was a fixed size on-chip memory which was basically sufficient for a single app.
                I have definitely experienced HyperZ bugs with my T60p / M66GL. And it can't be because of the compositor grabbing HyperZ because HyperZ doesn't get enabled unless I set an environment variable manually.

                Comment


                • #9
                  Originally posted by chrisr View Post
                  I have definitely experienced HyperZ bugs with my T60p / M66GL. And it can't be because of the compositor grabbing HyperZ because HyperZ doesn't get enabled unless I set an environment variable manually.
                  You're talking driver bugs though, not HW bugs ?

                  I was responding to Ericg's post #5.

                  Comment


                  • #10
                    *THIS* is why you need to develop open source drivers along with the hardware design itself. You can't develop open source drivers as a separate project, years after the hardware is released..
                    Also, a good reason why nvidia will probably never have decent open source drivers for all their hardware currently on the market. Who knows how many errata or other hardware design or performance problems you'll run into simply because you didn't take the exact same development path as the binary blob drivers.

                    Intel, you're doing it right.. AMD, you're *almost* doing it right... And nVidia, LOL.
                    Last edited by Sidicas; 09-10-2012, 11:51 PM.

                    Comment


                    • #11
                      Sounds like this might be going to be a fix for the Hyper-Z issues.
                      And I think AMD is trying to do it the right way, it's just that they're not as big as intel and they had to split up devs in 2 sections: An fglrx team and a "free team". And they had to catch up a lot with the free driver. Support is coming faster now, so one can hope that with the next generations (if there aren't big HW changes) some basic support or better might be available on HW release day.
                      Furthermore, intel doesn't have a binary blob to do or to compare with (let aside this relabeled imgtec stuff... omg).

                      Comment

                      Working...
                      X