OpenVG State Tracker For Gallium3D Tomorrow

[Craig73]

well having this hardware independent is pretty useful

Agreed... or separated from X :-)

[Craig73]

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

[Pfanne]

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?

[bridgman]

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.

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.

[Pfanne]

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!

[Craig73]

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