This wreaked havoc with intel_reg_dumper since it's been broken in
commit c6fe31bc473a7ae44bc42bad7da5faca3c924821
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Thu Jun 21 14:31:34 2012 -0300
intel_reg_dumper: use intel_register_access_init/fini
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While the Sandybridge PRM doesn't have any documentation on the GPU's
performance counters, a lot of information can be gleaned from the older
Ironlake PRM. Oddly, none of the information documented there actually
appears to apply to Ironlake. However, it apparently works just great
on Sandybridge.
Since this information has all been publicly available on the internet
for around three years, we can use it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to support this tool on more platforms. This lays the
groundwork for making that possible.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reads the GPU's performance counters via MI_REPORT_PERF_COUNT and
prints them in a top-style interface. While it can be useful in and of
itself, it also documents the performance counters and lets us verify
that they're working.
Currently, it only supports Ironlake.
v2 [Ken]: Rebase on master and fix compilation failures; make it abort
on non-Ironlake platforms to avoid GPU hangs; rename from 'chaps' to
intel_perf_counters since that acronym isn't used any longer; write the
above commit message.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add write-verify test to gem_fence_thrash. Test will create
multiple threads per fence then verify the write into fenced region.
v2: non-threaded, non-tiled tests added. suggested by Chris Wilson.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It was previously printing ironlake_debug_regs and haswell_debug_regs.
Since ironlake_debug_regs contains a lot of registers that don't exist
on Haswell, running intel_reg_dumper on Haswell caused "unclaimed
register" messages. Now I've copied the existing registers from
ironlake_debug_regs to haswell_debug_regs, so we won't print the
registers that don't exist anymore.
Also removed DP_TP_STATUS_A since it doesn't exist.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
This adds a test to make sure that the execbuffer validation routine is
checking for invalid addresses, single entry overflow, and multi-entry
wrapping overflow.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
flip-vs-bad-tiling tests that page flipping to a Y-tiled buffer returns
an error correctly, rather than triggering kernel BUG for instance.
Create a third fb for this purpose. After the fb has been created,
change its tiling mode to Y. When performing a flip, target this
Y-tiled fb and make sure we get the expected error value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The flip-vs-panning-vs-hang is just like the regular flip-vs-panning
test, except it also hangs the GPU. This will test whether panning
works after a pending page flip has been cancelled by a GPU reset,
and also whether page flip events get delivered correctly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Do not use the TEST_HANG flag to determine whether page flip events are
used. Add a new TEST_NOEVENT flag that can be used to disable the use
of events instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So when making changes in code using that function, we get warnings
about mismatches between the format string and arguments.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
dest_horizontal_stride needs go through the horiz_stride[] indirection
to pick up the rigth stride when its value is 11b (4 elements).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
sed -i -e 's/GLuint/unsigned/g' -e 's/GLint/int/g' \
-e 's/GLfloat/float/g' -e 's/GLubyte/uint8_t/g' \
-e 's/GLshort/int16_t/g' assembler/*.[ch]
Drop the GL types here, they don't bring anything to the table. For
instance, GLuint has no guarantee to be 32 bits, so it does not make too
much sense to use it in structure describing hardware tables and
opcodes.
Of course, some bikeshedding can be applied to use uin32_t instead, I
figured that some of the GLuint are used without size constraints, so
a sed with uint32_t did not seem the right thing to do. On top of that
initial sed, one bothered enough could change the structures with size
constraints to actually use uint32_t.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
I originally moved struct opcode_desc from brw_context.h to brw_eu.h on
the mesa side, but that was before the realization we needed struct
brw_context if we wanted to not touch the code too much.
So put it back there now that the mesa patch has been dropped.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
gen4asm.h is assembler specific while we want the library files to be
somewhat of a proper library.
This means that we have to redefine the GL* typedefs for brw_structs.h,
not using any of thet GL typedef will be for a future commit.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This allow us to factor out the test that checks if, when using both
predicates and conditional modifiers, we are using the same flag
register.
Also get rid of of a FIXME that we are now dealing with (the warning
mentioned above).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Like with the predicate fields before, there's no need to use the full
instruction to collect the list of options. This allows us to decouple
the list of options from a specific instruction encoding.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Right now we have duplicated code for when the option is the last in the
list or not. Put that code in a common function.
Interestingly it appears that both sides haven't been kept in sync and
that EOT and ACCWRCTRL had limitations on where they had to be in the
option list. It's fixed now!
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Rather than user a full instruction for that. Also use
set_instruction_predicate() for a case that coud not be done like that
before the refactoring (because everyone now uses the same instruction
structure).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Now that all instructions (relocatable or not) are struct
brw_program_instructions, this means we can move the relocation specific
information out the "relocatable instruction" structure. This will allow
us to share the relocation information between different types of
instructions.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This will be less typing for the refactoring to come (which is use
struct brw_program_instruction in gram.y for the type of all the
instructions).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Everything is now aligned to be able to use brw_set_src1() in the
opcode generation, so use it.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This way we ensure to have a single place where these are handled. The
immediate benefit is that now line numbers are always printed out, which
is quite handy.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Unfortunately, it's all a walk in the park. Both, internal code in the
assembler and external shaders (libva) generate registers that trigger
assertions in brw_eu_emit.c's brw_validate().
To fix all that I took the option to be able to emit warning with the -W
flag but still make the assembler generate the same opcodes.
We can fix all this, but it requires validation, something that I cannot
do right now.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
