We currently have two implementations of the same logic. Let's pick
the d3d12 one, move it to dxil_nir.c and let nir_to_dxil() call it
when appropriate.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17039>
Looks like some hardware needs this info in the shader to match the
topology. Since there's no spot in the shader info for it, we're
currently using the array size of the TCS input vars to store it.
Cc: mesa-stable
Reviewed-by: Paul Dodzweit <paul.dodzweit@amd.com>
Tested-by: Paul Dodzweit <paul.dodzweit@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16920>
Apparently we were only keying off the presence of a real stipple pattern
being set, and completely ignoring when the app does glDisable().
Add in the actual enable bit as an additional discriminator to determine
if we should be doing polygon stippling.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16254>
This controls the whole lowering of "make tex ops with implicit
derivatives on non-implicit-derivative stages be tex ops with an explicit
lod of 0 instead", but it's really hard to describe that in a git commit
summary.
All existing callers get it added except:
- nir_to_tgsi which didn't want it.
- nouveau, which didn't want it (fixes regressions in shadowcube and
shadow2darray with NIR, since the shading languages don't expose txl of
those sampler types and thus it's not supported in HW)
- optional lowering passes in mesa/st (lower_rect, YUV lowering, etc)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16156>
When we don't have a good dxcompiler.dll that we can load IDxcLibrary
from to help with diagnostics, we currently return true for validation
even if the validation actually failed.
Let's fix that, and also add a debug-message explaining what went wrong
for those who are debugging and wondering what's up.
Fixes: 2ea15cd661 ("d3d12: introduce d3d12 gallium driver")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15744>
This avoids undefined behavior in some cases, and in the case
where the new output varying is actually a sysval like viewport
index, the DXIL validator will require it to be written.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14881>
Turn the context state and shader key into a bitmask. When lowering
the depth invert into the shader, scan for writes to viewport index.
If found, move position to the end of the function (or current vertex)
and check if the current viewport needs the depth invert before applying.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14881>
DXIL doesn't support a single varying having components belonging
to multiple streams. For geometry shader outputs, whenever we find
this to be the case, break up that variable into multiple sub-
variables, and update stores to that variable to write to the new
sub-variables instead.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14787>
This pass was originally written for d3d12, but is useful for hardware
that lacks sample compare support like some etnaviv GPU models.
Also rename the lowering pass and some surrounding code to
nir_lower_tex_shadow as suggested by Emma.
I'd like to use the pass that's already in tree.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14308>
When multiple variables are packed into the same location, we need
to re-construct variables that read/write the same components of that
register so that the DXIL signature is correct. We could try to
merge these variables, but getting the types right sounds harder than
just preserving the multiple individual variables.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
GLSL puts a bunch of tessellation info in the eval shaders, because
passthrough control shaders can exist. D3D12 puts it in the control
(hull) shader instead. So, when specializing, copy info from domain
to hull. For initial compiles (no domain shader), just make something
up.
D3D12 also requires the domain and hull shaders to have identical
patch constant signatures. Use the existing infrastructure and extend
it to also propagate patch constants. Notably, patch constant locations
are outside of the 64-bit range value so they require a separate pass
to avoid shifts larger than 64.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
In the case of a multi-stream GS that is attempting to output wide
points to stream 0, we can support this by lowering stream 0 to
triangles and then removing the other streams. This is only valid
to do if the other streams are not being written to stream output,
either if they're not present in the SO info or no buffer is bound.
Fixes the arb_gpu_shader5/arb_gpu_shader5-emitstreamvertex_nodraw
piglit test which does this.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14624>
I couldn't find this in a spec but the builtin-gl-sample-mask piglit
seems to expect writing to the output sample mask to do nothing when
max num samples == 0.
The ForcedSampleCount property should make everything appear as if
MSAA is disabled. However, it's undefined behavior if depth is
bound, so in that case, we can at least use a lowering pass to
make things *look* like MSAA is off, unless you use atomics to
count invocations.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14624>
D3D doesn't have an intrinsic for loading the current sample's
position, only for loading a specific sample's intrinsic. Fortunately,
we can also just get the current sample. So do that.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14624>
This is handled in 2 ways:
* For casts in the same "class," we can just do the cast. There's also
limited support for 4x8 => 1x32 and 2x16 => 1x32.
* For casts that are just by size, use a lowering pass. This reads the
data in the appropriate UINT format (except R11G11B10), retrieves
the original bits, re-packs it into the dest, and returns it to the
app for loads. For stores, the process is done in reverse - bits
for the final format are computed and re-expanded to the format that
should be used for the store.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14342>
There are currently 3 different "environments" supported by this backend,
and they have slightly different semantics for how resources are accessed,
which is only going to get a little weirder when GL images start getting
supported. To try to make things less confusing, use an explicit enum
with heavy documentation on what's different between them.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14342>
Use of designated initializers requires at least '/std:c++20', and
mesa is using c++14 by default.
Fixes: 8d3a3e7a00 ("microsoft/compiler: Use textures for SRVs")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13912>
After running the (renamed) dxil_nir_split_typed_samplers pass, the
shader will have either:
* Textures, which map to D3D SRVs
* Bare samplers, which map to D3D bare samplers
* Images, which map to D3D UAVs
There shouldn't be any remaining samplers with type information
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13390>
