| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
They aren't used, and the backend was barfing on them. Also, remove a
hack in in compiler.cpp now that they're gone.
|
|
|
|
|
| |
We directly emit ubo load intrinsics based off of the offset information
handed to us from SPIR-V.
|
| |
|
|
|
|
|
|
|
|
|
| |
The GLSL layer above is still hacky, so we're really just moving the
hack into GLSL-to-NIR. I'd rather not go all the way and make GLSL
support the Vulkan binding model too, since presumably we'll be
switching to SPIR-V exclusively, and so working on proper GLSL support
will be a waste of time. For now, doing this keeps it working as we add
SPIR-V->NIR support though.
|
|
|
|
|
|
|
|
| |
This means that now the internal version of glslangValidator is
required. This includes some changes due to the sampler/texture rework,
but doesn't actually enable anything more yet. We also don't yet handle
UBO's correctly, and don't handle matrix stride and row major/column
major yet.
|
| |
|
| |
|
|
|
|
| |
Fixes valgrind errors with func.depthstencil.basic.
|
|
|
|
|
|
|
| |
Before values are pushed or annotated with a name, decoration, etc.,
they need to have an invalid type, NULL name, NULL decoration, etc.
ralloc zero's everything by accident, so this wasn't an issue in
practice, but we should be explicitly zero'ing it.
|
| |
|
|
|
|
|
| |
We may be able to revert this depending on the outcome of bug 14190, but
for now it gets vertex shaders working with SPIR-V.
|
|
|
|
| |
We were creating 2 extra bogus fields.
|
|
|
|
|
|
| |
We should be asserting that the parent decoration didn't hand us
a member if the child decoration did, but different child decorations
may obviously have different members.
|
|
|
|
| |
Also add support for more builtins.
|
|
|
|
| |
We need this to know if a deref is of a builtin.
|
| |
|
|
|
|
| |
This will handle decorations that aren't in the glsl_type.
|
|
|
|
|
|
|
| |
Since SSA values now have their own types, it's more convenient to make
'type' only used when we want to look up an actual SPIR-V type, since
we're going to change its type soon to support various decorations that
are handled at the SPIR-V -> NIR level.
|
| |
|
|
|
|
|
|
| |
Previously, the caller of vtn_handle_type had to handle actually inserting
the type. However, this didn't really work if the type was decorated in
any way.
|
| |
|
|\
| |
| |
| | |
Adds composites and matrix multiplication, plus some control flow fixes.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
When we're done emitting the code for a loop, we need to visit the new
break block, which is the merge block of the current loop, rather than
the old merge block, which is the merge block of the loop containing the
one we just emitted code for.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
We need to add FRAG_RESULT_DATA0 etc. to the input/output location.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This is kida sketchy. I'm not really sure this is the way it's supposed to
be used.
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes compilation failures in Dota 2 Reborn where a texture unit
binding point was used that was numerically higher than the max
per stage.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
Tested-by: Nick Sarnie <[email protected]>
Cc: "10.5 10.6" <[email protected]>
|
| | |
| | |
| | |
| | |
| | | |
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These are basically just moves, so they should be safe as well.
When disabling i965's GLSL IR level scalarizer (channel expressions)
pass, I started seeing NIR code like this:
if ssa_21 {
block block_1:
/* preds: block_0 */
vec4 ssa_120 = vec4 ssa_82, ssa_83, ssa_84, ssa_30
/* succs: block_3 */
} else {
block block_2:
/* preds: block_0 */
/* succs: block_3 */
}
block block_3:
/* preds: block_1 block_2 */
vec4 ssa_33 = phi block_1: ssa_120, block_2: ssa_2
Previously, the GLSL IR scalarizer pass would break the vec4 into a
series of fmovs, which were allowed by the peephole pass. But with
the vec4 operation, they were not. We want to keep getting selects.
Normal i965 on Broadwell:
instructions in affected programs: 200 -> 176 (-12.00%)
helped: 4
With brw_fs_channel_expressions() disabled:
instructions in affected programs: 1832 -> 1646 (-10.15%)
helped: 30
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Connor Abbott <[email protected]>
|
| | |
| | |
| | |
| | | |
Print the closing ) before the newline. Trivial.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's not totally clear whether other Mesa drivers can safely cope with
over-sized UBOs, but at least for llvmpipe receiving a UBO larger than
its limit causes problems, as it won't fit into its internal display
lists.
This fixes piglit "arb_uniform_buffer_object-maxuniformblocksize
fsexceed" without regressions for llvmpipe.
NVIDIA driver also fails to link the shader from
"arb_uniform_buffer_object-maxuniformblocksize fsexceed".
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65525
PS: I don't recommend cherry-picking this for Mesa stable, as some app
might inadvertently been relying on UBOs larger than
GL_MAX_UNIFORM_BLOCK_SIZE to work on other drivers, so even if this
commit is universally accepted it's probably best to let it mature in
master for a while.
Reviewed-by: Roland Scheidegger <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
gl_NumSamples should only be enabled when ARB_sample_shading is enabled.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|