CPU governor had no change, dual export is enabled.
Announcement
Collapse
No announcement yet.
2d tiling + sb -> no improvement in fill rate, curious
Collapse
X
-
Originally posted by curaga View PostCan't test swapbufferswait now (long downloads going), but that one is not really relevant, as tearing is unacceptable to me. It may turn out to be the wait causing the fillrate not to be up to hw specs, but since it has to be on, the question would then become "why didn't 2d tiling improve the fill rate".
SwapbuffersWait off, vblank_mode=0: Simple fill: 10.9 billion pixels/second
SwapbuffersWait on, vblank_mode=0: Simple fill: 7.7 billion pixels/second
As for the effect of 2d tiling, disabling it also results in a huge slowdown for me:
SwapbuffersWait off, vblank_mode=0, ColorTiling2d off: Simple fill: 6.8 billion pixels/second
So if 2d tiling doesn't make any difference for you, maybe it's not actually enabled with your gpu for some reason, or its effect is hidden by the SwapbuffersWait.
Comment
-
Originally posted by curaga View PostWill check dual export and cpu governor. Can't test swapbufferswait now (long downloads going), but that one is not really relevant, as tearing is unacceptable to me. It may turn out to be the wait causing the fillrate not to be up to hw specs, but since it has to be on, the question would then become "why didn't 2d tiling improve the fill rate".
Comment
-
Tested with swapbufferswait off - no change (!).
Simple fill: 1.3 billion pixels/second
Blended fill: 1.1 billion pixels/second
Textured fill: 1.2 billion pixels/second
Shader1 fill: 1.3 billion pixels/second
Shader2 fill: 516.6 million pixels/second
$ grep -i swapb /var/log/Xorg.0.log
[ 26040.404] (**) RADEON(0): Option "SwapbuffersWait" "off"
[ 26040.407] (II) RADEON(0): SwapBuffers wait for vsync: disabled
$ grep -i tilin /var/log/Xorg.0.log
[ 26040.406] (II) RADEON(0): KMS Color Tiling: enabled
[ 26040.406] (II) RADEON(0): KMS Color Tiling 2D: enabled
$ echo $vblank_mode
0
Comment
-
Code:Simple fill: 6.1 billion pixels/second Blended fill: 6.1 billion pixels/second Textured fill: 6.1 billion pixels/second Shader1 fill: 6.1 billion pixels/second Shader2 fill: 3.7 billion pixels/second
Last edited by Lemonzest; 29 May 2013, 02:36 PM.
Comment
-
Dear Watson, we have a conclusion.
On the bad side, it seems there is a constant overhead of 0.2-0.3 Gpix regardless of card position in the lineup and generation. This could be eliminated with driver advancements hopefully.
The no-op detection could also use some love.
On the good side, it turns out 1.3 is 81% not 55%. AMD you lying bitches, sure the units can push 2.3, but the VRAM can only push 1.6. Guess which number is mentioned in all marketing materials.
Comment
-
Originally posted by curaga View PostDear Watson, we have a conclusion.
On the bad side, it seems there is a constant overhead of 0.2-0.3 Gpix regardless of card position in the lineup and generation. This could be eliminated with driver advancements hopefully.
Originally posted by curaga View PostThe no-op detection could also use some love.
Originally posted by curaga View PostOn the good side, it turns out 1.3 is 81% not 55%. AMD you lying bitches, sure the units can push 2.3, but the VRAM can only push 1.6. Guess which number is mentioned in all marketing materials.
Comment
-
Originally posted by curaga View PostNo, the peak fillrate cannot be faster than what the memory can transfer.
Unless there is some live lossless compression, which I doubt there is.
Comment
Comment