This is a memory bandwidth tester based on the existing rendercopy tests
in IGT. Its purpose is to find regressions in the kernel driver and to figure
out where a bottleneck is. This test bypasses Mesa and goes directly to the kernel.
Say there is a performance regression. Where is it, Mesa or kernel? Just
compare the results of this test to the Mesa bandwidth results. If they are
similar, the problem is in the kernel. If Mesa is much slower than this test,
the problem is in Mesa.
Equivalent GLSL for the 'write' shader:
void main() {
gl_FragColor = vec4(1.0, 0.99, 0.5, 0.1);
}
Equivalend GLSL for the 'read' shader:
void main() {
gl_FragColor = texture2D(sourcebuf, gl_TexCoord);
discard;
}
I'm not too sure about my understanding of the shaders, especially the
one that does the discard operation (ps_kernel_read). Supposedly you
just need to set the output masks to 0 in the header of the final 'send'
and set some bits in 3DSTATE_PS_EXTRA. Halt instructions not needed since
I'm not doing any complicated flow control.
Someone more knowledgeable may want to review those shaders very closely.
Coming up soon: alpha blending versions of the copy and write tests.
Antti Koskipaa (3):
gem_render_copy: Make render_copyfunc more generic
gem_render_copy: Add functions for performance testing
gem_memory_bandwidth: Add test
lib/gen8_render.h | 3 +
lib/intel_batchbuffer.c | 40 +++++++++
lib/intel_batchbuffer.h | 2 +
lib/rendercopy.h | 12 +++
lib/rendercopy_gen8.c | 68 ++++++++++++--
shaders/ps/discard.g7a | 73 +++++++++++++++
shaders/ps/fill.g7a | 6 ++
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/gem_memory_bandwidth.c | 209 +++++++++++++++++++++++++++++++++++++++++++
10 files changed, 408 insertions(+), 7 deletions(-)
create mode 100644 shaders/ps/discard.g7a
create mode 100644 shaders/ps/fill.g7a
create mode 100644 tests/gem_memory_bandwidth.c
--
2.3.6
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
