Announcement

Collapse
No announcement yet.

OpenVG State Tracker For Gallium3D Tomorrow

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

  • #21
    Originally posted by Pfanne View Post
    well having this hardware independent is pretty useful
    Agreed... or separated from X :-)

    Comment


    • #22
      Originally posted by MostAwesomeDude View Post
      Close. The upper tiers of performance require a lot of expensive generalized optimizations. If an application runs slowly, we profile it, look at what parts are slow, and optimize those parts in the driver. As a bonus, other applications get faster too. Sometimes this is stuff like adding in support for new OGL extensions; sometimes it's things like redoing math routines in assembly. Whatever gets us more speed by eliminating bottlenecks, really.
      Thanks for clarifying (to you both). What's not clear to me is how much of this optimization is still available under Gallium3d without breaking the generalization too much; although I would presume there would be other optimizations available (new state trackers, state tracker tweaking, refactoring/redesign of the gallium generalizations, LLVM optimization improvements...likely tonnes to do yet)

      ...that being said, that is also being too narrow a focus. After the 80% is achieved, I expect that developer resources will get more low hanging fruit with more state trackers or other areas of the graphic stack.... perhaps an XOrg release for Michael ;-)

      Comment


      • #23
        does anyone actually know how good all these statetrackers work alongside eachother?
        for example im playing a game wich uses the direct3d statetracker(if this is ever going to happen) + compiz which is using the openglstate tracker while having physics effects in this game accelerated with opencl...
        will all this work well together, or will you notice a performance hit, that is higher than each tracker for itself?

        Comment


        • #24
          Originally posted by Craig73 View Post
          Thanks for clarifying (to you both). What's not clear to me is how much of this optimization is still available under Gallium3d without breaking the generalization too much; although I would presume there would be other optimizations available (new state trackers, state tracker tweaking, refactoring/redesign of the gallium generalizations, LLVM optimization improvements...likely tonnes to do yet)

          ...that being said, that is also being too narrow a focus. After the 80% is achieved, I expect that developer resources will get more low hanging fruit with more state trackers or other areas of the graphic stack.... perhaps an XOrg release for Michael ;-)
          Our guess was 60-70% of theoretical performance assuming something like Gallium3D but without a fancy shader compiler (LLVM or something else) for complex workloads.

          For simpler workloads (where the GPU is not shader-limited) I think the open source drivers will get a lot closer to 100%. Strictly speaking you probably don't need Gallium for that but I expect it will help.

          Originally posted by Pfanne View Post
          does anyone actually know how good all these statetrackers work alongside eachother?
          for example im playing a game wich uses the direct3d statetracker(if this is ever going to happen) + compiz which is using the openglstate tracker while having physics effects in this game accelerated with opencl...
          will all this work well together, or will you notice a performance hit, that is higher than each tracker for itself?
          I guess it depends mostly on how much video memory you have relative to the sum of all the buffer requirements for the different apps and state trackers. The memory manager can flip things between video and system memory but you take a performance hit if that happens much. An overloaded GPU will slow down predictably (2 tasks each run half as fast or better) but if you start thrashing video memory then you can quickly get a much larger drop in performance.
          Last edited by bridgman; 01 May 2009, 05:33 PM.
          Test signature

          Comment


          • #25
            Originally posted by bridgman View Post
            I guess it depends mostly on how much video memory you have relative to the sum of all the buffer requirements for the different apps and state trackers. The memory manager can flip things between video and system memory but you take a performance hit if that happens much. I'm mentioning that more than the obvious GPU load because an overloaded GPU will slow down predictably (2 tasks run half as fast or better) but if you start thrashing video memory then you can quickly get a larger drop in performance.
            so having a shitload of gpu memory can never be wrong
            thanks for the answer!

            Comment


            • #26
              Originally posted by Pfanne View Post
              so having a shitload of gpu memory can never be wrong
              thanks for the answer!
              Well only if it goes unused... which I'm sure most here would do their best and preventing

              Comment

              Working...
              X