And change the gen_sort_xml.py script to default to the new format.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36138>
It could be confusing that a newer platform named with a smaller
number than a half-generation of an older platform like 'gfx20' and
'gfx75' in xml files.
Down the road, it can be a little worse once we pass something like
'gfx40' when there is already a gfx45.xml for the oldest platform.
Unify naming xml files with verx10 numbers to resolve the issue.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31943>
Some older gens used '_' (underscore) while newer gens used a ' '
(space).
$ sed -i 's/Texture_Coordinate_Mode/Texture\ Coordinate\ Mode/' \
src/intel/genxml/*.xml
The naming needs to be aligned for importing enums later on.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24547>
This makes two relatively small changes, first it addes the encoding to
the xml delcaration, and switches the quote style. Second, it changes
the final newline. These seemed minor enough to not warrent patches to
make the old wrter do the same thing as the new writer.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18955>
This has been partly fixed twice before, but looks like some got missed.
Fixes arb_copy_image on gen4 with crocus
Fixes: de625dddee ("intel/genxml: fix raster operation field in blt genxml")
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14345>
The blitter commands don't show up in INTEL_DEBUG=bat, but on
gen4/5 they are emitted on the render engine ring so just change
the XML to reflect that.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10636>
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added addition engine definitions.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
A couple of typos found by inspecting field.end - field.start, revealed
a few wide integers declared as bool and some that ended before they
started.
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
MI_LOAD_REGISTER_IMM can load multiple (register, value) tuples in one
command. In our drivers we only use one tuple at a time, but the
kernel might load more than one at a time.
Instead of making all the tuple part of a group, we leave out the
first tuple (the one we use in the generated packing structures).
This is particularly useful for looking at error stats generated by
the kernel.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
We want people to be using ISL_FORMAT_*, rather than the genxml format
enumerations. This patch drops 10 separate copies, and drops a bunch
of ugly casting.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: Minor changes for rebase]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Original 965 sets bits 28:27 to 0, while G45 and later set it to 1.
Note that the G45 docs are incorrect in this regard - see the DevCTG+
note in the Ironlake PRMs.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
I decided to use the one-boolean-per-cube-face approach because it's
clearer which bits correspond to which cube face.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
On gen6+, this is called "Dispatch GRF Start Register For Constant/Setup Data
0", while on gen5 and lower it's called only "Dispatch GRF Start Register For
URB Data", but it's essentially the same thing (URB data), so rename it to
match newer gens and simplify the C code that handles it.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
"Pixel Shader Kill Pixel" -> "Pixel Shader Kills Pixel", which is how it's
called on newer gens.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
On gen4, WM_STATE only has one Kernel Start Pointer and one GRF Register
Count, but we can make the code that handles this on multiple gens simpler if
we add an index 0 to it too.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a bitmask, so it can't be a boolean. Also rename it so it matches
gen6+.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These fields are set by brw_clip_unit, so we need them when converting to
genxml.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes code generation on gen45.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Rename "Use Point Width State" to "Point Width Source". It accepts the same
values and has the same meaning as gen6+, so lets keep them with the same name
to simplify the code.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Gen6+ support multiple scissor rectangles, and define a SCISSOR_RECT
structure containing their dimensions. On Gen4-5, those same fields
exist in SF_VIEWPORT.
This patch extracts the SF_VIEWPORT fields into a SCISSOR_RECT
structure. Although not a named concept on Gen4-5, it works just
as well, and gives us a consistent SCISSOR_RECT structure across
all generations, making it easier to reuse code.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
It isn't a pointer to "color calc state", that's the packet it's in.
It's a pointer to the CC viewport state.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Most things on gen4-5 are addresses because we don't have dynamic state
base address and we don't have instruction state base on gen4. However,
whoever converted things to addresses got a little over-excited and
converted too much.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
There are two variants:
- Clip Enable
- CLIP Enable (on gen6)
Rename everything to Clip Enable.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Add some more details to Gen4 and Gen45 and add what is needed
in Gen5 XML. This commit overwrite the previous work done on Gen4
and Gen45 as it contains more instructions and fixes some mistakes.
However, comments (dword boundaries) are lost in the process.
v3:
- Set the type of some fields, instead of prefix. Also fix the
SAMPLER_BORDER_COLOR_STATE fields of gen5.xml.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
There's not much point to having them or not having them but this
reduces some pointless diff from the version we can auto-generate
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This is a work in progress - some things may still need fixing.
But it should be in pretty decent shape.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
THe offset type has special implications that it's intended to be some form
of aligned memory address. These assumptions allow it to handle the case
where there is some alignment requirement on the offset and the bottom bits
are used for other things. However, the offsets in the surface state field
are really just unsigned integers.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chad.versace@intel.com>
