Page 3 of 3 FirstFirst 123
Results 21 to 26 of 26

Thread: OpenVG State Tracker For Gallium3D Tomorrow

  1. #21
    Join Date
    Dec 2008
    Posts
    160

    Default

    Quote Originally Posted by Pfanne View Post
    well having this hardware independent is pretty useful
    Agreed... or separated from X :-)

  2. #22
    Join Date
    Dec 2008
    Posts
    160

    Default

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

  3. #23
    Join Date
    Sep 2008
    Posts
    332

    Default

    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?

  4. #24
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

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

    Quote 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; 05-01-2009 at 05:33 PM.

  5. #25
    Join Date
    Sep 2008
    Posts
    332

    Default

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

  6. #26
    Join Date
    Dec 2008
    Posts
    160

    Default

    Quote 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

Posting Permissions

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