Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: R600 Gallium3D Reorders Atom State Emission

  1. #1
    Join Date
    Jan 2007
    Posts
    15,391

    Default 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. #2
    Join Date
    Jun 2008
    Location
    Edinburgh, Scotland
    Posts
    448

    Default

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

  3. #3
    Join Date
    Dec 2008
    Location
    San Bernardino, CA
    Posts
    234

    Default

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

  4. #4
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    591

    Default

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

  5. #5
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,920

    Default

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

  6. #6
    Join Date
    Sep 2010
    Posts
    483

    Default

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

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

    Default

    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.

  8. #8
    Join Date
    Jul 2007
    Posts
    448

    Default I'm sure there are other issues.

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

  9. #9
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,541

    Default

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

  10. #10
    Join Date
    Jun 2011
    Posts
    316

    Default

    *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-11-2012 at 12:51 AM.

Posting Permissions

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