When Connor originally drafted NIR, he copied the same function+overload
system that GLSL IR had with a few names changed. However, this
double-indirection is not really needed and has only served to confuse
people. Instead, let's just have functions which may not have unique names
and may or may not have an implementation. If someone wants to do overload
resolving, they can hav a hash table based function+overload system in the
overload resolving pass. There's no good reason to keep it in core NIR.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
ir3 bits are
Reviewed-by: Rob Clark <robclark@gmail.com>
NIR has never been built with MSVC2008, so we shouldn't add
MSVC2008_COMPAT_CFLAGS to anything that uses it. This allows us to get
rid of the pragma in tgsi_to_nir.c.
Build tested with freedreno.
v2: Use MSVC2013_COMPAT_CLFAGS instead.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
This is kind of a hack, but it makes vtn_ssa_value insert a load if the
value requested is actually a deref. This shouldn't happen normally but,
thanks to the impedence mismatch of the NIR function parameter model vs.
the SPIR-V model, this can happen for function arguments.
Otherwise, we have a problem when we go to print functions with arguments
because their names get added to the hash table during declaration which
happens after we print the prototype.
The BDW PRM Vol2a: Command Reference: Instructions, section MEDIA_CURBE_LOAD,
says that 'CURBE Total Data Length' and 'CURBE Data Start Address' are
64-byte aligned. This is different from previous gens, that were 32-byte
aligned.
v2 (Jordan):
- CURBE Data Start Address is also 64-byte aligned.
- The call to brw_state_batch should also use 64-byte alignment.
- Improve PRM reference.
v3:
* New patch from Jordan. Always align base and size to 64 bytes.
Fixes the following SSBO CTS tests on BDW:
ES31-CTS.shader_storage_buffer_object.basic-atomic-case1-cs
ES31-CTS.shader_storage_buffer_object.basic-operations-case1-cs
ES31-CTS.shader_storage_buffer_object.basic-operations-case2-cs
ES31-CTS.shader_storage_buffer_object.basic-stdLayout_UBO_SSBO-case2-cs
ES31-CTS.shader_storage_buffer_object.advanced-write-fragment-cs
ES31-CTS.shader_storage_buffer_object.advanced-indirectAddressing-case2-cs
ES31-CTS.shader_storage_buffer_object.advanced-matrix-cs
And many other CS CTS tests as reported by Marta Lofstedt.
(Commit message is from Iago, but in v3, code is from Jordan.)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Everything is in place and I'm not aware of any further issues.
Tested with:
- Piglit
- Tessmark
- Unigine Heaven
- Shadow of Mordor
- GRID Autosport
I have patches to backport this to Haswell, Ivybridge, and Baytrail as
well (the first Intel hardware to support tessellation), but there are
still a lot of GPU hangs left to debug. So that will come later.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
GL_ARB_separate_shader_objects allows the application to mix-and-match
TCS and TES programs separately. This means that the interface between
the two stages isn't known until the final SSO pipeline is in place.
This isn't a great match for our hardware: the TCS and TES have to agree
on the Patch URB entry layout. Since we store data as per-patch slots
followed by per-vertex slots, changing the number of per-patch slots can
significantly alter the layout. This can easily happen with SSO.
To handle this, we store the [Patch]OutputsWritten and [Patch]InputsRead
bitfields in the TCS/TES program keys, introducing program recompiles.
brw_upload_programs() decides the layout for both TCS and TES, and
passes it to brw_upload_tcs/tes(), which store it in the key.
When creating the NIR for a shader specialization, we override
nir->info.inputs_read (and friends) to the program key's values.
Since everything uses those, no further compiler changes are needed.
This also replaces the hack in brw_create_nir().
To avoid recompiles, brw_precompile_tes() looks to see if there's a
TCS in the linked shader. If so, it accounts for the TCS outputs,
just as brw_upload_programs() would. This eliminates all recompiles
in the non-SSO case. In the SSO case, there should only be recompiles
when using a TCS and TES that have different input/output interfaces.
Fixes Piglit's mix-and-match-tcs-tes test.
v2: Pull the brw_upload_programs code into a brw_upload_tess_programs()
helper function (requested by Jordan Justen).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
With tessellation shaders and SSO, we won't be able to always decide on
VUE map layouts at LinkProgram time. Unfortunately, we have to delay it
until shader specialization time.
However, uniform lowering cannot be deferred - brw_codegen_*_prog()
reads nir->num_uniforms. Fortunately, we don't need to defer it -
uniform, system value, atomic, and sampler lowering can safely stay
where it is. This patch moves those to brw_lower_nir()'s only caller,
renames brw_lower_nir() to brw_nir_lower_io(), and introduces calls
to that.
For non-tessellation stages, I chose to call brw_nir_lower_io() from
brw_create_nir(), so it's still done at the same time. There's no
need to defer it, and doing it at LinkProgram time is nice.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This way, I can safely use brw_tcs_prog_key::program_string_id == 0
to mean "not filled out because no program exists", which avoids the
need for adding an extra boolean to that struct.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When the application hasn't supplied a TCS, and we have to create one,
we need to know what VS outputs to copy to TES inputs.
To do this, we create a new program key field, and set it to the TES
InputsRead bitfield.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When using tessellation on OpenGL without a TCS, default values for
gl_TessLevelOuter/gl_TessLevelInner are provided via the API.
Core Mesa will flag ctx->DriverFlags.NewDefaultTessLevels whenever those
values change. We add a corresponding BRW_NEW_DEFAULT_TESS_LEVELS flag
and hook it up to HS push constants (which will be used to upload these
default values to the autogenerated TCS).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
