They don't have a UIP. We used UIP in an array dereference, which never
caused problems on Gen < 8, since UIP was a small integer (number of
instructions). On Gen 8 UIP is in bytes, so it's large enough that it
caused us to read out of bounds of the array.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For now nothing uses this, but we can incrementally convert.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Use this an an opportunity to clean up the formatting of some old code
(brw_ADD, for instance).
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: (by Kenneth Graunke)
- Fix disassembly of Gen4-5 SEND messages to print base MRF correctly.
- Only print URB opcode on Gen5+, to match previous output (besides,
there is only one opcode AFAICT.)
- Only print the low 3 bits of msg_control, to match previous output.
(We probably should decode all the fields, but hadn't previously due
to the brw_instruction structure definition splitting out bits 4/5
for last_render_target and slot_group_select.)
- Fix 3-source MRF/GRF file decoding on Sandybridge.
- Fix compression code to use qtr_control rather than cmpt_control
(which is compaction, not compression).
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [v2]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Use brw_inst_bits rather than pulling out individual fields and
reassembling them.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We're going to use fs_generator/vec4_generator for Gen8+ code soon,
thanks to the new brw_instruction API. When we do, we'll generally
want to take the Haswell paths on Gen8+ as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2:
- Fix IF -> ELSE patching on Sandybridge.
- Don't set base_mrf on Gen6+ in OWord Block Read functions. (Although
- the old code did this universally, it shouldn't have - the field
- doesn't exist on Gen6+ and just got overwritten by the SFID anyway.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Don't set flag_reg_nr prior to Gen7 (as it doesn't exist).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is similar to gen8_instruction, and will eventually replace it.
For now nothing uses this, but we can incrementally convert.
The new API takes the existing brw_instruction pointers to ease
conversion; when done, we can simply drop the old structure and rename
struct brw_instruction -> brw_inst.
v2: (by Matt Turner) Make JIP/UIP functions take a signed argument.
v3: (by Kenneth Graunke)
- Make Gen4-6 jump target functions take a signed argument.
- Fix indirect align1 AddrImm bits on Gen4-7.
- Fix SFID on Sandybridge to use bits 27:24.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [v1, v3+]
Signed-off-by: Matt Turner <mattst88@gmail.com> [v2]
Reviewed-by: Matt Turner <mattst88@gmail.com>
The new brw_inst API is going to require a brw pointer in order
to access fields (so it can do generation checks). Plumb it in now.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
According to the workarounds list, these stalls aren't needed on
production Baytrail systems. Piglit confirms that as well.
These cause a small slowdown when we are sending a large number of small
batches to the GPU. Removing these improves performance by up to 5% on
some CPU bound SynMark tests (Batch[4-7], DrvState1, HdrBloom,
Multithread, ShMapPcf).
Signed-off-by: Gregory Hunt <greg.hunt@mobica.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Intel would like us to include the marketing names. Developers
additionally want "Broadwell GT1/2/3" because it makes it easier
to identify what hardware users have when they request assistance
or report issues.
Including both makes it easy for everyone to map between the names.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
The flags are not specific to the video targets plus
we can reuse them for targets/xa and targets/gbm.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Required for the conversion stage of all VL targets to
a single library per API (static/shared pipe-drivers).
No longer required as per last commit.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The radeonsi counterpart of previous commit - now libomx-radeonsi is
built into the libomx-mesa library. Providing a single library per API.
v2: Include the radeon winsys only when there is a user for it.
v3: Correcly include the winsys. Now with extra brown bag :\
Note: Make sure to rebuild the .omxregister file, by executing
$ omxregister-bellagio
This patch concludes the unification. Now libomx-mesa will be used
for all hardware - r600, radeonsi and nouveau.
Cc: Leo Liu <leo.liu@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The r600 counterpart of previous commit - now the libomx-r600 is
built into the libomx-mesa library. Providing a single library per API.
v2: Include the radeon winsys only when there is a user for it.
v3: Correcly include the winsys. Now with extra brown bag :\
Note: Make sure to rebuild the .omxregister file, by executing
$ omxregister-bellagio
If you have more than one omx library (libomx-radeonsi, libomx-r600),
make sure to temporary move the unused one. By the end of the series
there will be only one library that will be used for all hardware -
r600, radeonsi and nouveau.
Cc: Leo Liu <leo.liu@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Similar to the vdpau/xvmc targets, we're going to convert the
multiple target libraries into a single one.
The library can be built with the relevant pipe-drivers
statically linked in, or loaded as shared modules.
Currently we default to static.
Note: Make sure to rebuild the .omxregister file, by executing
$ omxregister-bellagio
If you have more than one omx library (libomx-radeonsi, libomx-r600),
make sure to temporary move the unused one. By the end of the series
there will be only one library that will be used for all hardware -
r600, radeonsi and nouveau.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Strictly speaking we should not have done this in the
first place, as all of the above should be static across
the system.
Currently this may cause some minor issues, which will be
resolved in the following patches, by providing a single
library for the OMX api.
Cleanup a few unneeded strcpy cases while we're around.
Note: Make sure to rebuild the .omxregister file, by executing
$ omxregister-bellagio
If you have more than one omx library (libomx-radeonsi, libomx-r600),
make sure to temporary move the unused one. By the end of the series
there will be only one library that will be used for all hardware -
r600, radeonsi and nouveau.
Cc: Leo Liu <leo.liu@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The number of components and their names/roles should
be kept constant as all of that information cached.
Note: Make sure to rebuild the .omxregister file, by executing
$ omxregister-bellagio.
Cc: Leo Liu <leo.liu@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Check calloc return value and report on error, also later skip
results handling if there was no memory to store results to.
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This only makes any sense on the GS input or output layout declaration,
nowhere else.
Fixes the piglit tests:
* spec/glsl-1.50/compiler/incorrect-in-layout-qualifiers-with-variable-declarations.geom
* spec/glsl-1.50/compiler/incorrect-out-layout-qualifiers-with-variable-declarations.geom
* spec/glsl-1.50/compiler/layout-fs-no-output.frag
* spec/glsl-1.50/compiler/layout-vs-no-input.vert
* spec/glsl-1.50/compiler/layout-vs-no-output.vert
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously we disallowed any combination of layout with interpolation,
invariant, or precise qualifiers. There is very little spec guidance on
exactly which combinations should be allowed, but with ARB_sso it's
useful to allow these qualifiers with rendezvous-by-location.
Since it's unclear exactly where the layout qualifier should appear when
combined with other qualifiers, we will allow it anywhere before the
auxiliary storage qualifier.
This allows enough flexibility for all examples I've seen, while keeping
the auxiliary-storage-qualifier / storage-qualifier pair together (as
they are a single qualifier in the spec prior to
ARB_shading_language_420pack)
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
